Method for directing and executing certified trading interests

ABSTRACT

Preferred embodiments of the subject invention comprise: (a) electronically receiving securities order-related data regarding a set of securities market participants; (b) electronically storing the received order-related data regarding the set of securities market participants; (c) electronically receiving a securities order-related query (or order parameters) from a first securities market participant; (d) based on the order-related query (or order parameters) received from the first securities market participant and on the securities order-related data regarding the set of securities market participants, computing a dissemination list of securities market participants based on ranking likely contras by probability of execution; and (e) transmitting that dissemination list to an entity who has been granted the privilege of receiving such lists in exchange for being contractually bound to respect confidentiality of the dissemination list and to use the list only for the purpose of sending securities-related information to members of the list.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a division of application Ser. No. 09/870,845, filedMay 31, 2001, which is a continuation-in-part of application Ser. No.09/750,768, filed Dec. 29, 2000, which is a continuation-in-part ofapplication Ser. No. 09/585,049, filed Jun. 1, 2000, now U.S. Pat. No.7,356,500, issued Apr. 8, 2008. The entire contents of each areincorporated herein by reference.

FIELD OF THE INVENTION

The subject invention relates to a method for managing certified tradinginformation to direct and execute confidential trading interests over acomputer network such as the Internet.

BACKGROUND THE INVENTION

The term “trading interest” is used herein to describe any expressedinterest in trading a given security or securities, and the term“certified trading interest” is used herein to describe a tradinginterest that has been verified as genuine and certified as such by sometrusted third party. One example of a genuine trading interest is anorder that has been placed on a securities market automatic matchingsystem. A second example of a genuine trading interest is a tradinginterest expressed by a party with a documented history of aggressivetrading. An example of a trading interest that would not be certified isan undocumented indication of interest (known in the art as an 101).

In public securities markets, market mechanics and trading psychologycreate barriers to efficient information dissemination and pricediscovery. A market participant's decision to reveal informationregarding a large trading interest typically represents a tradeoffbetween confidentiality and liquidity. As used herein, the term “marketparticipant” refers to any person or firm with the ability to tradesecurities; examples of market participants include broker-dealers,buy-side firms, sell-side firms, and private investors trading onelectronic communication networks (ECNs). “Buy-side” firms are thosethat buy new issues of securities, as distinct from broker-dealer firmsthat “sell” such new issues.

By publicly revealing the details of a significant active buyinginterest, for example, a market participant assumes the risk of adverseprice action. Other market participants with legitimate sellinginterests and market makers can “fade” their offers (become much lessaggressive sellers). There is also an empirically demonstrable risk ofadverse price action due to “front running” (buying activity by marketparticipants in anticipation of price movement resulting from the largerevealed order). Confidentiality can be maintained by splitting thelarge order up into many small orders to avoid arousing interest, butthis is inefficient and will fail to attract substantial naturalcontra-interests. An economically efficient transaction is thereforemissed because the trading costs associated with disseminatinginformation are too high. Also, the common practice of splitting largeinterests into smaller orders affects all price discovery. Whenconfronting each order, a market participant must incorporate thepossibility that the order is only a small part of a much largerinterest, because it is often impossible for the market participant toverify that many such orders are not being sent simultaneously.

Another serious obstacle to efficient dissemination of trading interestsand price discovery is the lack of validated information about tradinginterests. The validated trading interest information which does exist(e.g., displayed executable orders) is often of little assistance.Displayed orders are minuscule compared to undisclosed interest, andtypically equate to no more than one or two minutes of trading in aliquid stock in the U.S. market. Displayed orders can therefore beeasily manipulated, for example, to indicate excess buying interest whensellers are in fact abundant. In addition, non-validated misinformationis often created and disseminated by unscrupulous market participants tomanipulate market prices. Voluntarily disseminated trading interests canbe false or misleading if they are not verified either by proof of acurrent executable order, actual trades executed, or canceled orderswhich were at one point executable at risk in the market. Because thereis often no way for a market participant to verify an expressed tradinginterest or to know which other market participants have a history ofunscrupulous trading behavior, all prices must incorporate thepossibility of such behavior.

One known approach to voluntary selective dissemination of non-validatedtrading interests and activity in public equity markets is used by theAutEx+® system. This is an electronic database and online network thatprovides users with the ability to voluntarily publicly indicate tradinginterests and executed trades. AutEx+® users can limit the recipients ofa message regarding a trading interest by inclusion (a user-definedlist) or exclusion (blocking specific named market participants). Userscan also limit by name the securities on which they receive informationand the other users from whom they receive information.

In the AutEx+® system the expressed trading interests and reportedtrades are not certified, however, and this creates the opportunity fordeceptive dissemination of tracking information. In addition, users ofthe system are not obligated to report all trades, which offers furtheropportunities to create false impressions of trading interests.Significantly, this approach does not permit the use of certifiedtrading interests (CTI) to limit information dissemination to thosemarket-participants likely to have a contra-interest. It also does notenable using such CTI analysis to permit market participants to limitthe trading interest indications received. It also does not provide theability to initiate an auction based on disseminated CTI analysisinformation. It also does not enable the monitoring of user tradingactivity to generate a rating of the accuracy of disclosures or thecorrelation of trading activity to inappropriate trading practices.

One known approach to matching trading interests and executing tradeswhile limiting information dissemination is employed by the POSITSmatching system. The POSITS system allows trading interests toaccumulate and initiates a matching sequence at set intervals. Marketparticipants place confidential orders in the system and are unaware ofthe amount or aggressiveness of other orders on the same or contra sideuntil the matching is released. This approach does not enable targetedcommunication of trading interests based on analysis of verifiedexecutable interests and trading activity, and does not provide theability to initiate private auctions based on this analysis. It alsodoes not permit granting the auction initiator any exclusivity overcontra-orders entered in response to the targeted dissemination.

In this environment, there is an acute need for efficient disseminationof confidential information regarding trading interests. Marketparticipants with large confidential trading interests wish to notifyonly those other market participants likely to have a significantcontra-interest. Other market participants wish to be notified ofconfidential certified trading interests to which they are likely tohave a contra-interest. Both groups wish to have a place to transact atrade once they have been connected through analysis of their certifiedtrading interests. Market participants also desire a means of certifyingexpressed trading information and access to certified informationregarding the trading behavior of other market participants.

SUMMARY

Preferred embodiments of the subject invention overcome the limitationsof known trading interest dissemination and execution systems by (1)enabling market participants to limit dissemination of trading intereststo only those other market participants likely to have a significantcontra-interest, (2) enabling market participants to ensure that othermarket participants' disseminated trading interests are legitimate, and(3) enabling auctions among trading interests targeted and validated inthis manner. Software of a preferred embodiment identifies likelycontra-interests by analyzing information from various sources regardingcertified trading interests.

A preferred embodiment comprises a method of managing marketinformation, comprising the steps of: electronically receivingsecurities order-related or trade-related data regarding a set ofsecurities market participants; electronically storing said receivedorder-related or trade-related data regarding said set of securitiesmarket participants; electronically receiving a securities order-relatedor trade-related query from a first securities market participant; basedon said order-related or trade-related query received from said firstsecurities market participant and on said securities order-related ortrade-related data regarding said set of securities market participants,computing a dissemination list of securities market participants; andtransmitting said dissemination list to an entity who has been granted aprivilege of receiving such lists in exchange for being contractuallybound to respect confidentiality of the dissemination list and to usethe list only for the purpose of sending securities-related informationto members of the list.

Further embodiments are described below.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic diagram depicting a preferred embodiment of thesubject invention.

FIG. 2 is a schematic diagram depicting a preferred system for targeteddissemination of confidential information regarding trading interests.

FIG. 3 is a flowchart illustrating steps of a preferred method oftargeted dissemination of confidential information regarding tradinginterests.

FIG. 4 is a flowchart showing steps of a preferred method of matchinginterests identified by targeted dissemination in an auction execution.

FIG. 5 is a flowchart showing steps of a preferred order routingembodiment.

FIG. 6 is a flowchart showing steps of a preferred order managementembodiment.

FIG. 7 is a flowchart showing steps of a certified trading interestquery ranking embodiment.

FIG. 8 is a flowchart showing steps of an order depository embodiment.

FIG. 9 depicts a graphic user interface of a preferred embodiment.

FIGS. 10-20 are flowcharts showing steps of further embodiments.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 illustrates a system configuration of a preferred embodiment ofthe subject invention that comprises a certified trading interest (CTI)manager 10 connected to various users 20 via a communication network 30.CTI manager 10 is a computer comprising a processor, a memory, andinput/output including a communications interface. Computer programsstored in the memory operate the CTI manager in accordance with theinvention. In the preferred embodiment, communication network 30 is theInternet, but alternate embodiments can employ dedicated communicationnetworks, as is well known in the art. In the preferred embodiment,communication between users and the CTI manager is secured, because ofthe confidential nature of the information communicated. The CTI manager10 is also connected to various external data sources 40, a CTI userdatabase 50, and an auction server 60.

External data sources 40 provide information regarding positions held,trades executed, and active orders for the users 20. This enables theCTI manager to identify and verify users' historical and current tradinginterests. In an alternate embodiment, the CTI manager does not receiveexternal data, but only uses data generated within the system. In apreferred embodiment applied to the U.S. equity market, the externaldata sources 40 include various electronic communication networks (ECNs)such as Instinet™, public markets such as NASDAQ™, stock exchanges,matching networks such as POSIT®, and publicly available data such asthe published holdings of various institutional investors. In apreferred embodiment, the data regarding market participants used by theCTI manager comprises confidential information. For example, theidentity of an executable order on an ECN is not typically available.Since the confidential information is not publicly available, the CTIsystem must obtain permission from the users 20 to utilize it. In thepreferred embodiment users 20 agree to release this confidentialinformation to the CTI system, with the understanding that the secureCTI system will use the information only for supplying the user withvaluable confidential trading interests of others. In other words, theconfidential information with which users 20 entrust the CTI manager 10gives them access to more information (in particular, certified tradinginterests), but the confidential information provided by users 20 doesnot leak out to third parties.

In a preferred embodiment, the CTI manager 10 communicates in real timewith external data sources 40 via the Internet. Alternate embodimentsemploy dedicated communication networks as is well known in the art.Also, alternate embodiments store information from external data sources40 in a database and update the information periodically rather than inreal time. For example, an alternate embodiment receives informationregarding the published holdings of various institutional investors,stores the information in a database, and updates the information fromthe news service source only as frequently as new information ispublished. As will be apparent to those skilled in the art, the subjectinvention could also be used to direct confidential information inmarkets other than U.S. equities, since virtually all markets forfungible items of value pose the same informational inefficiencies.

In a preferred embodiment, the CTI user database 50 contains user datasuch as security and contact information, CTI notification parameters,and an activity history. The preferred embodiment maintains an activityhistory for each user that includes auctions initiated and their outcome(e.g., whether the auction was canceled, unsuccessful in locating acontra-interest, or resulted in a partial or full execution of theinitiating interest). The activity history also includes the CTInotifications received, the orders placed in response, and their outcome(whether the responding order was canceled, unsuccessful, or resulted ina partial or full execution of the response order). In an alternatepreferred embodiment, the CTI user database 50 simply maintains overallstatistics regarding this activity history for each user.

The CTI notification parameters specify the circumstances in which CTIinformation is to be received and can be different for differentsecurities and different users. For example, some users may limit CTInotifications to initiating interests over 100,000 shares for certainsecurities and 500,000 shares for others. In a preferred embodiment thenotification parameters can be modified by the user at any time, and canbe on the basis of order size, security, identity of initiating user, orstatistics regarding the initiating user's activity history.

In an alternate preferred embodiment, the CTI user database 50 alsocontains information regarding inappropriate trading behavior such aspeg gaming and front running. Peg gaming is possible when an auctionsets the execution price to be the market midpoint at a specific time.An auction participant with a large buy order might sell actively in themarket to pull the midpoint price down. Front running is possible inthis context if, for example, a recipient of a notification of a largebuy order starts buying CTI trades actively before the auction inanticipation of price action caused by the large CTI. The CTI manager ofthis embodiment will monitor the trading activity of all auctionparticipants and note any suspected peg gaming or front running in theCTI user database, either as raw data or as a rating of tradingbehavior. An alternate embodiment maintains similar data and/or ratingsin the CTI user database 50 regarding the accuracy of the marketparticipants' non-certified disclosures on external systems such asAutEx+®. A further embodiment maintains similar data and/or ratings inthe CTI user database 50 regarding the market participants' adherence toself-imposed trading limits set during negotiations. This list is notintended to be exhaustive; other embodiments will be apparent to thoseskilled in the art.

The auction server 60 manages the process of accumulating marketparticipant (MP) contra-orders in response to a CTI notification andexecuting a matching auction. In an alternate embodiment, there is noauction server and the CTI system functions as a targeted informationdissemination mechanism. FIG. 2 depicts the information managementfunction of a preferred embodiment of the subject invention. Aninitiating user 210 communicates to the CTI manager a trading interestand parameters that limit the dissemination of the information. The CTImanager uses these parameters and CTI information 230 to determine whichmarket participants 240 should receive the information. Also, each MPcommunicates his own parameters to the CTI manager delineating thetrading interest information that the MP desires to receive. The CTImanager therefore acts as a bilateral CTI information filter 220. Itlimits dissemination of the initiating user's confidential informationto those MPs 240 for which (1) the MP fits the initiating user'sdissemination parameters, and (2) the initiating interest fits the MP'snotification parameters. In an alternate embodiment, the CTI manager isonly a unilateral information filter in which the system targets MPs tonotify but does not allow the MP to similarly filter notifications.Comparing FIG. 1 and FIG. 2, in a preferred embodiment both theinitiating user 210 and the market participants 240 are users 20 of thesystem, the bilateral CTI information filter 220 is the CTI manager 10,and the CTI information 230 is supplied by the external data sources 40and the CTI user database.

FIG. 3 is a flow diagram of the operation of an information managementfunction of a preferred embodiment. In step 310, a user communicates aninitiating interest to the CTI manager. In the preferred embodiment, theinitiating interest is a live executable order submitted to the CTIsystem to initiate an auction, but in alternate embodiments theinitiating interest can be other information that the CTI system mustthen certify. For example, the user may wish to selectively disseminatethe existence of a large executable order that a user has placed inanother market or auction system such as an ECN or POSIT®. The userwould submit information regarding the order, and the CTI system wouldthen verify the existence of the claimed order, so that all marketparticipants subsequently notified of the order can rely on thetruthfulness of the dissemination. Similarly, the user can submit anindication of interest, which the system then certifies from verifiedinformation regarding current executable orders, recent trading history,and/or canceled orders which were once executable but were not filled.Once again, all market participants subsequently notified of theinterest can rely on the truthfulness of the dissemination. In analternate embodiment, the user can submit a non-certified tradinginterest, but this lack of certification is indicated to all marketparticipants subsequently notified.

In a preferred embodiment, the initiating interest includes a pricelimit, which can be a nominal value (e.g., $112½) or pegged to a marketprice when the price is set (e.g., market midpoint set at thetermination of the auction). Alternate embodiments enable the initiatinguser to peg the price limit to a yet-to-be-determined market value orindex. For example, in an alternate embodiment the user can peg theprice limit to the daily volume weighted average price (VWAP) as will becalculated at the end of the trading session. In the preferredembodiment, the initiating interest includes auction parameters such asthe length of the period during which the CTI system is to accumulateresponses from the market participants (the “accumulation period”).

In step 320, the user communicates the desired dissemination parameters.In the preferred embodiment, there are many dissemination parametersavailable to the user, the most important being various measures ofcertified contra-interest. In the preferred embodiment, the user canspecify certified contra-interest from (1) live executable orders; (2)past executed trades; or (3) canceled orders that were once executablebut were not filled. Examples of CTI-based filtering of dissemination ofan interest to buy 500,000 shares of a certain stock include limitingdissemination to (1) MPs or other system users presently offering 10,000or more shares of that stock in the marketplace; (2) MPs or other systemusers who have sold over 25,000 shares of that stock in the currenttrading session; (3) MPs or other system users who have offered blocksof over 10,000 shares of that stock in the current trading session; or(4) MPs or other system users who have bought at or above the Nationalmarket Best Offer in the current trading session. The quantities andtime horizons in these parameters are all selectable by the user.

In a preferred embodiment, there are many other parameters available tothe user that employ market information from the external data sources40 and the CTI user database 50 to more accurately target disseminationto desired market participants. For example, the user can choose tonotify only those market participants with certain response orinitiation statistics (e.g., directing the CTI manager to notify onlymarket participants who have responded to 10% of CTI notificationsreceived in a certain time frame or to a certain total number of CTInotifications). In addition, the preferred embodiment enables the userto target MPs with certain known holdings in the security of interest.The preferred embodiment also enables users to exclude MPs fromnotification on the basis of their history of trade breaks (e.g.,preventing CTI information from reaching any MP who has broken somequantity of trades in some period of time). The preferred embodimentalso enables users to include or exclude specific MPs from notificationby name or identification number.

In an alternate preferred embodiment, the user can also target MPs basedon more sophisticated analysis performed by the CTI manager on thetrading patterns of various users to identify certain correlations orpatterns (e.g., buyer of technology stocks, sector rotation, etc.). Inanother preferred embodiment, the user can exclude MPs based on anyidentified inappropriate trading behavior such as front running and peggaming stored in the CTI user database 50. In another alternateembodiment, the dissemination parameters are system-defined and notselectable by the user. In yet another alternate embodiment, the usercan choose between defining some or all of the dissemination parametersand using system-defined default parameters. Preferred database queriesand query mechanisms are discussed below in greater detail.

Referring back to FIG. 3, at step 330 the CTI manager accesses thenecessary CTI information from the external data sources 40 and the CTIuser database 50 to perform the CTI filtering analysis. At step 340, theCTI manager analyzes CTI information using the dissemination parametersand produces a list of MPs to notify. At step 350, the CTI managerfurther reduces the MP notification list using the MP notificationparameters stored in the CTI user database 50. At step 360, the CTImanager sends notification of the confidential initiating CTI to thoseMPs for which (1) the MP fits the initiating user's disseminationparameters, and (2) the initiating interest fits the MP's notificationparameters. In an alternate embodiment, the notification includesstatistics regarding the initiating user's past auctions (e.g.,proportion filled, cancel rate, frequency of trade breaks, etc.).

In an alternate preferred embodiment, after step 350 the initiating useris shown a summary of the results of this analysis and is given theoption of modifying the dissemination parameters given in step 320 tomore accurately tailor/limit the dissemination of confidential CTI. Forexample, a user can modify dissemination parameters that are tooinclusive (e.g., too many MPs have sold 10,000 or more shares of therelevant security today) or exclusive (e.g., there are no MPs whocurrently have a live order to sell over 50,000 shares). The productionof the MP notification list is an iterative process in this embodiment,as the embodiment repeats steps 330-350 until the user is satisfied withthe output of the dissemination analysis. The user interaction in thisiterative process is performed through interface means that are wellknown in the art.

In a further alternate embodiment, the adjustment is done by the systemwithout sending information back to the recipient, based on adjustmentrules set by the user beforehand. For example, if a user enters a queryto find the buyers of more than 10,000 shares net during the past hour,but wishes to notify no more than 4 counterparties, this query requestmay be amended by a request to extend the time period to more than onehour if the number of contraparties found in the past hour was less than4 or, in the opposite case, where more than four large buyers were foundin the time period, by a request to reduce the time span of the query. Asimple example of a self-adjusting query is one that seeks the mostrecent net buyer or seller of at least a given number of shares. If noone has accumulated a position of this size in a given time period, itwould return the largest accumulator during said time period. This querywill return exactly one counterparty, unless there have been no tradesin the day, in which case the user would be notified that nocounterparty could be identified for lack of trading data in thatsecurity. These examples of self-adjusting dissemination rules areintended for the purpose of illustration only and not as an exhaustivelist; other self-adjusting dissemination rules will be apparent to thoseskilled in the art.

FIG. 4 is a flow diagram of the operation of the CTI management systemin executing an auction based on the disseminated initiating interest.At step 405, notification of an auction initiated by a CTI isdisseminated to MPs targeted in the process depicted in FIG. 3. At step410, the notified MPs have the option of responding to the notification.In the preferred embodiment, this response is an executableprice-limited contra-order sent to the auction server. As with theinitiating interest, in the preferred embodiment the price limit can beeither a nominal value or pegged to a market price. Alternateembodiments enable the responding MP to peg the price limit to a yet tobe determined market value or index. For example, in an alternateembodiment the MP can peg the price limit to the end of day VWAP.

An alternate embodiment enables the notified MPs to simultaneouslysubmit a trading interest and send a message to the initiating user todirectly negotiate a trade. Another alternate embodiment enables thenotified MPs to respond via a private chat session to directly negotiatea trade. Alternate preferred embodiments also enable the MP to respondin a semi-private negotiation chat session with the initiating user andsome or all of the other notified MPs. The system provides the chat andmessaging functionality using interactive communication technology as iswell known in the art. Alternate preferred embodiments also provide thenotified MPs with the initiating user's phone number and/or e-mailaddress to provide other channels of direct communication.

In step 420, the auction server 60 accumulates orders from the notifiedMPs. In the preferred embodiment, the duration of the accumulationperiod is set by the initiating user in the auction parameterscommunicated in step 310, subject to a system-defined minimum andmaximum. This enables users of the CTI system to initiate auctions atany time and limit them to MPs with verified contra-interest, in sharpcontrast with the POSIT® system in which users must wait for periodicmatching sessions which are not targeted in any way. In alternateembodiments, there is a fixed, system-defined accumulation period. Inanother preferred embodiment, the system sets the end of theaccumulation period, subject to a minimum and maximum. If possible, thesystem sets the end of the accumulation period to match the end of theaccumulation period of any other pending auction so that the auctionscan be combined to increase total liquidity. In the preferredembodiment, during the accumulation period, the initiating user and thenotified MPs can modify or cancel their orders placed in the auctionserver. Alternate embodiments place restrictions on this ability. Forexample, an alternate embodiment does not permit the initiating user tocancel the auction after notified MPs have responded with contra-orders;the initiator is locked into the order once a MP has relied on it torespond with a contra-order.

In step 430, the auction server 60 of a preferred embodiment prioritizesthe contra-orders sent by notified MPs. The preferred embodiment createsan execution priority by the following sequential rules:

-   1) Total matched size—Combinations of contra-orders are chosen which    maximize total size executed.-   2) Price limit—If competing MP contra-orders would produce equal    matched quantities, the auction server will first execute MP    contra-orders with more aggressive price limits.-   3) Size limit—If competing MP contra-orders have the same (or no)    price limit, the auction server will first execute orders with more    aggressive size limits.-   4) Time of entry—If competing MP contra-orders have the same size    limit, the auction server will first execute orders entered earlier.

Alternate embodiments that employ different execution priority ruleswill be apparent to those skilled in the art. For example, one alternateembodiment ignores the size limit of the contra-order; in anotheralternate embodiment, where there are no price limits and actualexecution is at the market midpoint at the moment of matching, executionpriority is by time of entry.

The above description assumes that the initiating interest is the onlyorder on one side, and all orders sent to the auction server by notifiedMPs are on the contra-side. It is possible that a notified MP respondswith an order on the same side as the initiating interest, necessitatingan execution priority for that side as well. In a preferred embodiment,the initiating interest has absolute execution priority over subsequentMP orders. This is an additional benefit of the CTI system from theinitiating user's perspective. The system enables the initiating user totarget dissemination of a confidential trading interest to MPs with acertified contra-interest, to influence the auction timing, and obtainpriority in matching over contra-orders placed in response. All ordersplaced by notified MPs on the same side as the initiating interest areexecuted only after the initiating interest is filled, and according tothe execution priority outlined above. Once again, alternate embodimentsthat employ different execution priority rules will be apparent to thoseskilled in the art. Furthermore, in an alternate embodiment, theinitiating interest is not granted absolute priority over competingorders subsequently placed by notified MPs, and must compete accordingto the ordinary execution priority.

In another embodiment, more than one auction can be combined to poolliquidity. In a combined auction, each initiating interest is givenexclusivity over contra-orders placed by notified MPs in response tothat respective initiating order. By “exclusivity” it is meant that acontra-order placed in response to an initiating order cannot be matchedwith any other order until the initiating order is filled or canceled.In an alternate preferred embodiment, there is no priority orexclusivity granted to the initiating orders in a combined auction, andall orders compete according to the same execution priority. Alternateembodiments that employ other means of combining auctions will beapparent to those skilled in the art.

In step 440, the auction server executes the orders according to theexecution priority set in step 430, all at a price set by the type ofauction employed. If there are no MP responses or no trade is possiblegiven the limit prices, the auction is unsuccessful and is terminated.In a preferred embodiment, the auction server employs a midpoint crossauction, where all orders are executed at market midpoint at a certaintime. To avoid peg gaming, in the preferred embodiment the executionprice is pegged to market at a random time during a ten minute “fuzzperiod” after the end of the accumulation period. In an alternateembodiment, there is no fuzz period and the auction execution price isdetermined at a known time after the end of the accumulation period.

In an alternate embodiment, there is no system-imposed accumulationperiod or fuzz, but the system offers randomly-timed match events, andusers who initiate a transaction have the option to submit thecorresponding response orders to an accumulation period to (1) createcompetitive bidding conditions; (2) expose their initiation order toimmediate execution against response orders as they come in on afirst-come-first-served basis; and/or (3) expose their initiation orderto the above-mentioned random match-check events when such events takeplace. Preferably, the random match-check events are scheduled with aconstant probability per unit of time. This result can be achieved witha computer by generating a pseudo-random number in the range (0,1) andsetting the delay between one match-check event and the next equal tothe logarithm of this pseudo-random number. The timing of the day'smatch-check events is stored in the system but is not disclosed to theusers. Users who enter orders specify whether the order should (1)subject response orders to a holding period before they can match, forthe purpose of generating competitive auction conditions; (2) expose theoriginating order to an immediate match-check event following theexpiration of the holding period, if any; (3) expose the originatingorder to immediate execution against response orders on afirst-come-first-served basis (following the expiration of the holdingperiod, if there was one); or (4) expose the originating order toexecute in randomly-timed match-check events.

For example, a user could use this system in the following ways: (1) toenter an order that will be exposed only to randomly-timed match-checkevents, removing the advantage of market timing for the contra party.(2) Enter an order that a notified party can execute at any time byentering a response order. This transaction gives the recipient thebenefit of market timing, and may in return ask for a better price.Preferably, the notified parties are aware of these order-handlingrules, so they know how their response order will be handled, andspecifically, whether it will execute immediately or be placed on holdfor a randomly-timed event. In a further alternate embodiment the systemdisplays only the usual facts about the order and the order-handlingrules remain hidden. In a still further alternate embodiment, the orderis displayed as a passive order and executes immediately against contraorders at that price (such as the inside market best bid or best offer),but upgrades its price to the midpoint for possible crossing againstsimilar orders on the contra side in the event of randomly-timed eventswhere neither party has control of the execution time. In this hybridembodiment, the value of the market timing option is displayed to theorder recipient, allowing both market makers (liquidity providers forwhom the market timing option is of most value) and “natural” contrasseeking midpoint executions to participate, each in their naturalmanner. In an extension of the hybrid embodiment, the initiating ordersimply displays two prices, which do not have to be the inside market ormidpoint prices but can be fixed limit prices or prices pegged relativeto a market value such as the midpoint price minus $0.03; the moreaggressive price is accessible only to respondents who are willing torenounce the market timing option by leaving their order on hold untilthe next match-check event.

Alternate embodiments employ various other auction types. For example,one alternate embodiment employs a “sealed envelope” auction where thelimit price on all orders is kept confidential, and a single price ischosen to maximize the size of the matched execution. Another embodimentemploys a “private outcry” auction where the initiating user and allnotified MPs can see all orders and their limit prices as theyaccumulate, and there is price competition among the responding MPs totrade with the initiating interest. The examples given assume that allorders are executed at the same price; another alternate embodimentemploys discriminatory pricing where all orders from responding MPstrade at their limit price. This list is not intended to be exhaustive,as alternate embodiments that employ different auction types will beapparent to those skilled in the art. An alternate embodiment enablesthe initiating user to choose from more than one different auction typesuch as those described above.

In step 450, the auction server informs the initiating user and allresponding users of the status of their respective orders (i.e., “fill,”“partial execution,” “canceled,” “open,” “expired”). In step 460, theauction server of the preferred embodiment enables participants in theauction to communicate with each other and a system administrator toresolve any perceived errors. In a preferred embodiment thiscommunication is via semi-private chat messaging, but alternateembodiments supply telephone contact information. Users can break thetrade or negotiate an amendment during a temporary window, after whichthe trade is final. The use of this window represents a tradeoff betweenthe interest in instant finality to trades and the interest inminimizing the costs and disruption caused by errors. An alternatepreferred embodiment does not offer a temporary window to negotiatechanges to the executed auction. In step 470, the CTI manager 10processes the auction activity and updates the CTI user informationdatabase to reflect the initiation, response, execution, and trade breakactivity that took place.

In an alternate preferred embodiment, the auction server 60 alsocontains a depository of orders not related to an active auction. Inthis embodiment, any user can place an order in the depository withoutinitiating an auction or invoking CTI targeted notification. Theseorders are dormant until an auction is initiated in that stock, at whichtime they are treated by the auction server as a response received froma notified MP in step 410. In an alternate embodiment, the auctionserver performs a match at periodic intervals without any CTI initiationto clear out the depository of dormant orders. An alternate embodimentperforms these auctions only when sufficient dormant interest hasaccumulated, rather than at defined intervals. In yet anotherembodiment, these orders are not dormant and are continuously executablesubject to their price limit, as in an ECN. Another embodiment enableslive execution but with a price limit defined relative to an externalprice, such as the market midpoint or a certain spread to the end of dayVWAP.

In an alternate embodiment, the user entering an order into the orderdepository can specify relevant order-handling rules. Examples include:(1) whether the order will be exposed to random match-check events; (2)whether it will be exposed to other orders being entered into the systemas depository orders; (3) whether it will be exposed to orders with aCTI notification request attached (hereinafter “advertised orders”). Inembodiments comprising an order depository, the user entering anadvertised order can preferably also specify whether or not this orderwill be exposed to the incoming depository orders. By letting an orderexecute against an entered contra order immediately, as opposed tolimiting this process to randomly-timed match events, the party enteringan order is expressing the willingness to be “picked off” by a contraparty who might be blindly probing the system to grab any availableliquidity in light of newly released price-affecting news.

In an alternate embodiment, the system specifies order-handling rulesthat are fair for all participants, and advertises these rules for allto understand. Preferably, the advertised order is exposed to immediateexecution against response orders—it is not exposed to immediateexecution against orders submitted to the order depository, or againstother initiation orders that are not responding to the notification ofthe advertised order. Response orders have a first chance to matchagainst the corresponding initiators, and are eligible to match againstany other order thereafter; depository orders are exposed only to randommatch-check events. In an alternate set of system-imposed order-handlingrules, the initiator's order is only exposed to execute immediatelyagainst respondents who pay a more aggressive price; midpoint responsesare stored until the next randomly-timed match-check event. This list oforder-handling default rule-sets is intended only for the purpose ofillustration; it is not intended to be exhaustive, and otherorder-handling default rule-sets will be apparent to those skilled inthe art.

Notification on near misses: in an alternate embodiment, a user enteringan order can request that a message be generated to notify any party whoenters an order on the contra side that is close to matching but doesnot quite have the right price or sufficient size for a match.Preferably, the user specifies what price or size differential defines a“near miss.” For example, such a definition might state that the priceshould be within $0.03 of the order's limit price and that the sizeshould be no less than ½ of the order's minimum execution quantity, orthat the second order's minimum quantity should be no greater than 1½times the first order's size. This is an example of routing CTI messages(notifications of an order) based on CTI information (the fact that thesecond participant entered an order with nearly matching conditions).

In an alternate embodiment, the notification on near-misses is alsoavailable when the order has already been the subject of anothernotification, in which case a second notification event may take placeregarding the same originating order. When a single order is subject tomultiple notifications, the order-handling rules apply as they relate tothe particular notification that the response is related to. Forexample, one notification may indicate that response orders wouldexecute immediately on a first-come-first-served basis, while anothernotification of the same order would receive responses in a book to beconsidered in a random match-check event. In a hybrid notification, therespondent chooses to pay up for an immediate execution or wait for abetter price by placing an order in the book and wait for a randommatch-check event.

In a further alternate preferred embodiment, there is no auction serveror execution functionality, and the CTI system functions as the targetedinformation dissemination mechanism depicted in FIG. 2. In thisalternate embodiment, after the notification process depicted in FIG. 3,the CTI system does not perform the auction process depicted in FIG. 4,but rather enables the notified MPs to respond to the initiating uservia a private or semi-private negotiation chat session as describedabove. Alternate preferred embodiments also provide the notified MPswith the initiating user's phone number and/or e-mail address to provideother channels of direct communication. After the initiating interestexpires or is canceled, the preferred embodiment updates the CTI userdatabase to reflect the initiation and response activity.

In an alternate embodiment, a third-party matching facility, such asOptimark, uses the CTI system to drum up liquidity for a match, thenexecutes the match. For example, a MP may send an order to Optimark andrequest that a notification be sent out announcing: “There is an orderfor DELL in Optimark for the next round; please participate.” In thisembodiment, there is no chat, but there is an address (in the example,Optimark's) where the match is to be executed.

In a further preferred embodiment, the CTI system functions in a mannerroughly analogous to a rating service. In this embodiment, the systemcompares non-certified disseminations of trading activity (such as thedisclosures on AutEx+®) to actual certified information, to generate ameasure of the overall accuracy of market participants' disclosures.This accuracy rating can be used by other market participants todiscriminate among the disclosures on the basis of demonstratedtrustworthiness.

In another embodiment, the CTI system rates a market participant'scompliance with the MP's own stated trading limits. For example, when aMP is negotiating a trade, in order to receive a better price the MP mayagree to be bound to a trading cap, to demonstrate that the presentorder is not part of a much larger trading interest, and that the MP isnot simultaneously negotiating similar trades with other MPs. The CTIsystem can compare the MP's stated trading limits to actual certifiedinformation, to generate a measure of the MP's demonstratedtrustworthiness. This rating can be used by other MPs to accuratelyprice the likelihood that a negotiated order is part of a much largerorder.

In an alternate embodiment, service bureau functionality is based on asubsystem hosted by the DTCC [need definition], where queries areexecuted to confirm whether or not a given user has exceeded the statedcap on the number of shares to accumulate in the given day. In thisembodiment the subsystem receives a data feed from an InstitutionalDelivery (ID) system containing information on the buy-side party thatis involved in each trade. Preferably, the result of the query is notdisclosed back to the system of the present invention, but only aBoolean (yes/no) descriptor of the party's compliance with statedtrading cap is disclosed, upon permission by the institution concerned.Failure to permit said verification is handled in the same manner as afailure to comply with the trading cap: compliance statistics arereported to the trading counterparty in subsequent attempts to negotiatea trade using a trading cap.

In an alternate embodiment, the subsystem is not hosted by the DTCC, butby the first participant's custodian firm. In a further alternateembodiment, a large institutional custodian hosts the system. Custodiansare another natural throttling point where the vast majority or all of aparticular institution's trading data is available. In a furtheralternate embodiment, the system is permitted to execute queries againstclient institutions' order management systems, to verify that thetrading caps are being respected. Preferably, this access can bepermitted or denied, either system-wide or on each query request. Asabove in the case of access denial, said denial can be subsequentlyreported as part of compliance statistics.

In the above order management embodiment, participants are contractuallybound to respect the integrity of the software that locally receivesquery requests and executes them against the OMS database, as well as torespect the integrity of the OMS database itself so that the informationin said database accurately reflects the participant's executed trades.The contract can also include a right to have a third-party consultingfirm inspect and verify compliance with said contractual terms. In afurther alternate embodiment, a clearing firm hosts the system thatexecutes queries against the trading data. This embodiment of theservice bureau issues certificates on the voluntary compliance of theircorrespondents to stated trading limitations.

In a further embodiment, the CTI system monitors a MP's trading activityfor correlation to inappropriate trading behavior, to generate abehavior rating. In this embodiment, the CTI system monitors MP activityfor suspected front running. When the system becomes aware that a MP hasbeen notified of a large trading interest (e.g., from an auctionnotification on the system or through a CTI disseminated over thesystem), the system monitors the subsequent trading activity of notifiedMPs to analyze correlation between their trading activity and therevealed CTI.

In another embodiment, the CTI system monitors MP activity for suspectedpeg gaming. The system monitors the trading activity of MPsparticipating in auctions (on the CTI system or on another system suchas POSIT®) in which the price is set relative to a market price such asthe midpoint. This trading activity is monitored for negativecorrelation to represented auction orders (e.g., MPs who sell while abuy order is represented in the auction), which indicates a possibleattempt to manipulate the price of the auction execution. In anotherembodiment, the behavior rating also incorporates information regardingthe MP's history of trade breaks.

In all of these “rating service” embodiments, the MP being rated permitsthe CTI system to use confidential information to rate the MP's pastbehavior (e.g., disclosures, trade breaks, inappropriate tradingactivity) in order to receive better prices on future trades or moreorder flow. This rating information is stored in the CTI user database50 and can come in many forms, as will be apparent to one skilled in theart. Examples of ratings forms include numerical data (percentdivergence between disclosed and actual trading activity or betweenstated trading cap and actual trading activity), boolean indicators (hasthe market participant exhibited inappropriate trading behavior or not),or scaled ratings (rating from 1 to n that incorporates informationregarding various trading activity scaled according to, for example,recency and frequency of certain activity, degree of correlation toinappropriate behavior, etc.). These examples are not exhaustive, andmany representations of the rating data will be apparent to thoseskilled in the art. In an alternate embodiment, an MP may request that arating “certificate” be provided to a potential counterparty, todemonstrate to the counterparty the trustworthiness of the MP. Thecertificate is a certified report based on the MP's market behaviorhistory.

These embodiments provide the described “rating service” function inaddition to the auction and execution functionality described in FIG. 4;the ratings can also be used as a dissemination parameter in theseembodiments. Alternate embodiments that provide the rating function donot offer the execution functionality and operate as the targetedinformation dissemination mechanism depicted in FIG. 2; the ratings canbe used as a dissemination parameter in these embodiments as well. Otherembodiments simply operate as a certification and rating system, and donot offer execution or targeted dissemination functionality. Preferably,the previously described rating supports additional functionality forusers to determine whom they wish to notify of their orders. The systemdoes not notify users of said statistics on the analysis offront-running activity by other MPs, but users are aware of whichstatistical parameters are maintained in the system and can set theirown conditions to avoid notifying parties whose past trading statisticsindicate a high likelihood of front-running activity, or any of theother ratings described above.

For example, users are able to exclude from notifications any user forwhich adverse price impact followed receipt of a notification in atleast 65% of the cases and where the sample set contained at least 10previous notifications. In an alternate embodiment, the system has adisclosed rating equation that produces a single no-front-running targetquality indicator (a number from 0 to 10) and users choose the minimalnumber that will be required for a recipient to receive a notification.In an exemplary implementation, this quality indicator is equal to 10minus the number of times in the last 10 notification events adverseprice movement of less than $0.1 followed the notification in thesubsequent 5 minutes, minus twice the number of cases where said adverseimpact was greater than $0.1, plus the number of times the price impactwas favorable to the originator of a notification, or 10 if the abovecalculation gave a result greater than 10. Other implementations of asystem-defined rating system will be apparent to those skilled in theart.

In another alternate embodiment, the rating follows from an equationthat is not disclosed to the parties, and is subject to being modifiedwithout notice, so that it becomes impossible for users to findloopholes allowing them to front-run with impunity by occasionallyacting in a way that will increase their score though an understandingof the scoring algorithm.

In all of these embodiments, Market Participants agree to submit theirtrading data to this analysis or renounce the opportunity to receivenotifications from initiators that include a no-front-running scoringrequirement in their notification parameters. In an alternateembodiment, the agreement is not required on a case-by-case basis butinstead the agreement to submit data for front-running analysis is partof the general agreement to use the system.

In an alternate embodiment there is no equation giving a score but therating is replaced by a simpler “penalty box” mechanism. In thisembodiment, users who receive notifications of an order of at least 100shares displayed and do not enter a response order for at least thelesser of 1000 shares or the received order size will be marked as“uninterested” in that symbol and side and therefore ineligible toreceive further notifications during a 30-minute period. A user canreaffirm his or her interest in trading this symbol and side by enteringan order for at least 1000 shares with notification parameters chosen sothat at least one other party is included in the disseminationlist—thereby creating a genuine liability.

In an alternate embodiment the originator of a notification can decidewhether a penalty box should be applicable (to exclude from potentialnotification recipients who have recently failed to respond), and mayinclude the penalty box duration (other than the 30-minute defaultvalue) and the minimum size required to be placed in the penalty box (orto leave the penalty box by entering an order), as part of thedissemination parameters.

A further embodiment of the subject invention is directed to orderrouting and order management based on CTI information. One element thatdifferentiates the subject invention from other systems and methods isits use of confidential information on a one-way basis: MPs supplyconfidential information to a preferred system in order to attracttrading interest notifications; this confidential information is neverreleased to other MPs.

Current order routing and management systems are based on publicinformation only—for example, Tradescape will route an order to Instinetif Instinet is currently showing the best price, and offers fasterexecutions than other MPs (such as Market Makers that implicitlyguarantee the same price)—but Tradescape does not know whether or notthis best-priced order on Instinet has a large reserve size. In apreferred embodiment of the subject invention, Instinet sends itsclient's reserve size information confidentially, knowing that the onlyusage made of that data will be to send a large-sized order that can hitthe reserve size if the opportunity comes up. Other sources ofconfidential information, besides reserve size information, wouldinclude the data on clients' past trading activity, and other CTIinformation sources, including those described elsewhere in thisdescription.

An order routing embodiment is disclosed in FIG. 5. At step 510 thesystem receives an order and dissemination parameters. At step 520, itcreates a dissemination list as described above, and at step 530 ranksthe market participants on the dissemination list and identifies themarket participant that is the most likely to take the contra side tothe trade. At step 540, the order is routed to the identified MP.

There are several ways to rank market participants, depending on the CTIinformation. The ranking rules can be any one or an ordered combinationof the following:

First, by size: if the MP's CTI information comprises orders, then theMPs will be ranked according to the size of these orders; if the CTIinformation comprises trades executed in the recent past, the systemwill rank MPs by total net size traded in the past N minutes (buys minussells), or by gross traded volume (buys plus sells): for routing a sellorder, larger net or gross buyers are ranked higher than smaller ones,while for buy orders the system will rank large net sellers or totalamount traded ahead of smaller players. For example, if a user specifiesdissemination parameters that seek to notify the 10 biggest net buyersduring the past 2 hours, the system will execute a query to return aranked list containing the 10 market participants that have accumulatedthe largest net quantities of stock during that time interval.

Second, by price aggression: the price aggression is the price of theorder or trade, relative to the bid ask spread. Let B denote the bestbid on the National Market, A the best offer and P the price of theorder or trade, then the aggression X is given by X=(P−B)/(A−B) forbuys, and X=(A−P)/(A−B) for sells. Higher price aggression levels willbe ranked ahead of less aggressive orders or trades.

Third, by time: route the order preferably to MPs that executed thetrade most recently.

A preferred order routing service preferably combines several of thesecriteria to break possible ties. For example, the system could route anorder to the largest recent buyer in the last 30 minutes, choosing themost recent execution in the event of a tie. Other ranking rules will beapparent to those skilled in the art.

An order management embodiment of this invention is an extension of theorder routing system described above. In this embodiment, the systemfirst routes the order to the top-ranked participant, as describedabove. If the order is not executed, the system then routes the order tothe next-most-likely contra in the ranked list of market participants.This process is iterated until either the order gets executed, or auser-specified limit is reached on the maximum number of MPs that can benotified.

A preferred embodiment of the order management implementation is shownin FIG. 6. The system receives at step 610 an order and disseminationparameters. At step 620 a dissemination list is created, and at step 630the MPs on the dissemination list are ranked as outlined above. Forexample, a user requests the system to query the trade database for thetop 10 biggest buyers of DELL in the past 15 minutes, ranked by totalnet number of shares purchased, and in the case of a tie, choosing theone with the most recent trade. The system then receives the orderelectronically, stores the order, and at steps 640-660 works the orderwith the ranked dissemination list. At step 640, it routs the order tothe highest-ranked MP and at step 650 it tests whether the order hasbeen executed. If the order has not been executed or if the order hasreceived a partial fill but has not been completely executed, the systemcalculates the residual quantity and proceeds at step 660 by routingorders for that residual quantity until the order is completely filledor the list of 10 MPs is exhausted.

Alternatively, a user may have an order sitting passively in the orderdepository (discussed above), and decide to “market” the order byinitiating the order management process described above, for example bysending it to the ten most likely contras in ranked order.

In an alternate embodiment, a user can send parts of an order out tothird-party systems and leave the remainder in the matching book,exposed to order entry events and/or random match-check events, aspreviously described. The aggregate size of the orders that are routedaway from the system (hereinafter “exported quantity”) preferably doesnot exceed the size of the order itself, so as to avoid a multipleliability problem wherein more shares could be executed than the orderwas good for. Preferably, the system is an open platform allowing thirdparties to advertise their own routing alternatives, and users canchoose to “export” size to a combination of possible execution options.

In an alternate embodiment, routing options include the above-mentionedorder routing embodiment that uses CTI information to intelligentlyroute orders to likely contras, and other order routing embodiments thatwill be described below. In an alternate embodiment only the CTI-basedrouting options described herein are made available. When a routed-outorder is declined by the counterparty or its time-in-force expires, theexported quantity attribute on the order in the system book isdecremented to reflect the fact that this liability has vanished. In anextension of this embodiment, the user is allowed to enter a scriptthrough a Graphical User Interface (GUI) specifying the sequence ofoperations that should be executed in the process of “working” theorder, including (possibly multiple) notifications with specificdissemination parameters. Order routing events where part or all of theorder are sent to parties likely to execute said order parts, and thetime interval allotted for completion of each instruction in the script,are specified by the user.

To enable the writing of such order management scripts, a GUI preferablyoffers the user a script-editing screen displaying a blank horizontalfield with a downward-pointing arrow. Upon clicking on the arrow a droplist of order management options (“notify . . . ”; “route to . . . ”;etc.) is displayed. Upon selecting an item from this list, the userenters a dialog to edit the relevant dissemination parameters. Defaultvalues for the parameters are offered for convenience, but can bemodified as needed by the user. When the user has completed the step ofspecifying dissemination and order-handling rules for one step of thescript, he selects the time that will be allotted for execution of thisstep and presses an “OK” button, at which point the order managementscript is incremented with the just-specified order managementinstruction and a new blank horizontal line is displayed at thehigher-level script-editing screen, with a downward-pointing arrow.

The user may again click on the arrow to select a new order managementtool, enter a dialog to specify the second order management instructionand save it by pressing OK, having created at this point a scriptcontaining two consecutive order management steps that will be executedconsecutively. By iterating this process the user can spell out acomplete order management strategy. Having done this, the usersubsequently submits the order with the attached order managementstrategy. The system stores the order parameters as well as the ordermanagement script, sets a timer to release messages that will triggerthe beginning and end of each step in the order management strategy, andcarries on with the sequential execution of each step as described indetail in other sections herein. Execution of order managementinstructions that require routing the order or parts thereof to thirdparties must be implemented through interfaces to said third partysystems, using techniques and communication methods that are known inthe art.

In an alternate embodiment, the confidential data that is used to createdissemination lists includes data on the past behavior of MPs followingthe delivery of CTI Notifications. In this embodiment, MarketParticipants must first agree to let other users request that customqueries and analytic calculations be executed on this confidential datato determine whether the MPs past behavior indicates a good track recordof responding to notifications rather than front-running on theinformation. The only effect of permitting this access to an MP'sconfidential data is that the MP will then get a chance to receive moreinformation, in the form of CTI Notifications. For example, a relativelysmall broker-dealer may rarely have the size to rank among the “top 10buyers,” but may respond affirmatively to CTI Notifications in almostall cases. Such a user would permit his past responding data to beanalyzed, and thereby attract more CTI Notifications from userstargeting MPs with a good track record in the system.

In this embodiment the user is allowed to enter an executable algorithmthat will access the past usage data from participating MPs, and produceas output a ranked list of target MPs. The past usage data that isexposed to such algorithms comprises, for each participating MP, a listof past notification events comprising, in each case: (1) the sizedisplayed in the notification; (2) the reason the MP was targeted (forexample, bought 15000 shares during the past 30 minutes); (3) the MP'sresponse (none, response order smaller than displayed size, equal to, orgreater than displayed size); and (4) the price fluctuation followingthe notification event.

Users can combine the usage of the trade database and the past behaviordatabase by entering requests for queries that combine information fromboth. For example, a user may enter dissemination parameters thatspecify that the notification should be sent to: the 10 biggest buyersexcluding those that have received notifications in the past and neverentered a response order.

In an alternate implementation users enter algorithms that access allavailable data, including the CTI information database and the pastusage database, and attempt to estimate based on this data theprobability that any one MP would execute their order. They then eithersend notifications to the most likely contras, or draw on the ordermanagement function to route their order to the ranked list of mostlikely contras until either the order is filled or the list isexhausted. This embodiment requires an “analytic toolkit” (discussedbelow) to determine the probability of a match from data including CTIinformation and past events. The system allows users to submit their owncustom tools, or to propose a “generic” probability-reconstructing tool(described below).

The probability that a MP in the dissemination list would execute anorder can be calculated from data on how similar order routing eventshave unfolded in the past. This is required (1) when some MPs have beenincluded in the dissemination list due to information on orders whileothers are in the list due to information on trades, so that there is nosingle comparable number that can be used to rank one relative to theother, and (2) when the MPs differ significantly in how they respond tonotifications. For example if an institutional desk such as RSSF hasbeen a net buyer in the past hour, it is likely to continue to buy, butif a retail Market Maker such as NITE has been a net buyer, it may needto reverse course and return to a neutral inventory position—so thatwould not be such a good target for a sell order. Another example ofcase (2) is one where an order is routed based on displayed size: again,different MPs will react differently to an oversized order. Ordersdisplayed in institutional ECNs such as Instinet are more likely to havereserve size than retail-centric ECNs, and different Nasdaq MarketMakers will have different rules on when to accept non-liability orders.In both cases (1) and (2), the system relies on a database of pastevents where orders were routed to given MPs and either executed (inpart or in whole) or rejected. The probability of execution can beestimated from this statistical sample-set using a statistical estimatormethod that is described below. If there is not enough past data on agiven MP to compute the probability of execution, the MP is assumed tobehave like the average MP and data from all MPs is used to determinethe “generic” probability of execution, which is then used to rank thisMP in the dissemination list.

The first case to consider is that where a MP provides information on anorder to buy s_(o) shares of stock, and the task is to determine theprobability that this MP would execute a larger order for s>s_(o)shares. The probability of execution of an order of size s>s_(o), wheres_(o) is the displayed size, can be calculated for individual MarketParticipants based on their response to past orders, using a statisticalestimator approach, as described next. The probability function isassumed to be well-approximated by a generic parametric function such as

${{P\left( {1;\frac{s - s_{o}}{s_{o}}} \right)} = \frac{a}{1 + {b\left( \frac{s - s_{o}}{s_{o}} \right)}^{\gamma\;}}},$that fits well to the distribution of trade sizes as can be observed inpublicly-available data. The parameters a, b, and γ are determined usingan empirical approach and a sample-set of past order-routing events, bymaximizing the probability of the sample-set. Each sample in the setcomprises an order size s, a displayed order size s_(o), and a bit (0or 1) specifying whether the order was accepted (1) or only received apartial fill equal to the known size s_(o) (0). Relatively infrequentevents such as race conditions where the executed size is neither s_(o)nor s are discarded from the sample-set for simplicity. If we callξ_(n)=(0 or 1) the rejection (0) or acceptance (1) of the oversizedorder in sample number n,

${x_{n} = \frac{s_{n} - s_{o}}{s_{o}}},$the probability of the sample set is

${P\left\lbrack {{sample}\mspace{14mu}{set}} \right\rbrack} = {\prod\limits_{\{{{n|\xi_{n}} = 1}\}}\;{{P\left( {1;x_{n}} \right)}{\prod\limits_{\{{{n|\xi_{n}} = 0}\}}\;{P\left( {0;x_{n}} \right)}}}}$

This probability is greatest when the derivatives of log(P) with respectto each of the three parameters are equal to zero, namely when

${F_{1} \equiv {{\sum\limits_{\{{{n|\xi_{n}} = 0}\}}\frac{1}{\alpha - 1 + {\beta\; x_{n}^{\gamma}}}} - {\sum\limits_{n}\frac{1}{\alpha + {\beta\; x^{\gamma}}}}}} = 0$${F_{2} \equiv {{\sum\limits_{\{{{n|\xi_{n}} = 0}\}}\frac{x_{n}^{\gamma}}{\alpha - 1 + {\beta\; x_{n}^{\gamma}}}} - {\sum\limits_{n}\frac{x_{n}^{\gamma}}{\alpha + {\beta\; x^{\gamma}}}}}} = 0$${{F_{3} \equiv {{\sum\limits_{\{{{n|\xi_{n}} = 0}\}}\frac{x_{n}^{\gamma}{\log\left( x_{n} \right)}}{\alpha - 1 + {\beta\; x_{n}^{\gamma}}}} - {\sum\limits_{n}\frac{x_{n}^{\gamma}{\log\left( x_{n} \right)}}{\alpha + {\beta\; x^{\gamma}}}}}} = 0},{{{where}\mspace{14mu}\alpha} = {{\frac{1}{a}\mspace{14mu}{and}\mspace{14mu}\beta} = \frac{b}{a^{*}}}}$

The solution of this set of three non-linear equations can be foundusing methods known in the art, such as the Newton-Raphson algorithm[Numerical Recipes in C; Cambridge University Press 1988, 1992; pp.379]. An initial approximate solution is required for this algorithm toconverge: to obtain an approximate initial value of the exponent γ_(o),we represent the available data in a histogram format, using logarithmicx and y axes, and determine the asymptotic slope of this graph for largevalues of x. The value of this asymptotic slope is then equal to −γ_(o).Given this approximate value of the exponent, approximate values α_(o)and β_(o) are obtained analytically by least-squares approximation. TheNewton-Raphson algorithm can then be used to find a better approximationof the solution. This algorithm converges quadratically.

The second case is that where the CTI information that was used to placea MP on the dissemination list was trade information. In that case onefirst determines the total number of shares bought (sold) by that MP inthe past interval of time, calling this number once again s_(o). Usuallythe order to be delivered would be for a smaller number of shares, butthat is not required. Once again the system uses a database of pastevents to reconstruct the parametric probability distribution, and todetermine the values of the parameters that maximize the probability ofthe sample-set. In this case, there are three possible outcomes toconsider in an order routing event: as before, the order can bepartially executed (Σ_(n)=0) or filled (Σ_(n)=1), but also, in thiscase, since the MP has no open order, it is possible that the ordercould be rejected altogether. We will represent this possibility by thevalue Σ_(n)=*:

${P\left\lbrack {{sample}\mspace{14mu}{set}} \right\rbrack} = {\prod\limits_{\{{{n|\xi_{n}} = 1}\}}\;{{P\left( {1;x_{n}} \right)}{\prod\limits_{\{{{n|\xi_{n}} = 0}\}}\;{{P\left( {0;x_{n}} \right)}{\prod\limits_{\{{{n|\xi_{n}} = \star}\}}\;{P\left( {\star {;\; x_{n}}} \right)}}}}}}$where  now   ${x_{n} = \frac{s_{n}}{s_{o}}}\mspace{14mu}$ and  ${{P\left( {1;x} \right)} = \frac{a_{1}}{1 + {bx}^{\gamma}}},{{P\left( {0;x} \right)} = \frac{a_{0}}{1 + {bx}^{\gamma}}},{{P\left( {\star {;x}} \right)} = {1 - {P\left( {0;x} \right)} - {{P\left( {1;x} \right)}.}}}$Once again the probability is maximized when the partial derivatives oflog(P) are equal to zero, leading to the set of four non-linearequations:

${G_{1} \equiv {\frac{N_{1}}{a_{1}} - {\sum\limits_{\{{{n|\xi_{n}} = \star}\}}\frac{1}{1 - a_{0} - a_{1} + {bx}_{n}^{\gamma}}}}} = 0$${G_{2} \equiv {\frac{N_{0}}{a_{0}} - {\sum\limits_{\{{{n|\xi_{n}} = \star}\}}\frac{1}{1 - a_{0} - a_{1} + {bx}_{n}^{\gamma}}}}} = 0$${G_{3} \equiv {{\sum\limits_{\{{{n|\xi_{n}} = \star}\}}\frac{x_{n}^{\gamma}}{1 - a_{0} - a_{1} + {bx}_{n}^{\gamma}}} - {\sum\limits_{n}\frac{x_{n}^{\gamma}}{1 + {bx}^{\gamma}}}}} = 0$${{G_{4} \equiv {{\sum\limits_{\{{{n|\xi_{n}} = *}\}}\frac{x_{n}^{\gamma}{\log(x)}}{1 - a_{0} - a_{1} + {bx}_{n}^{\gamma}}} - {\sum\limits_{n}\frac{x_{n}^{\gamma}{\log(x)}}{1 + {bx}^{\gamma}}}}} = 0},$where N₀ and N₁ are the number of samples where the order was partlyexecuted and filled, respectively. The first two equations yield

${a_{1} = {a_{0}\frac{N_{1}}{N_{0}}}};$this value of the parameter α₁ can be substituted in equations G₂, G₃,and G₄, to obtain three coupled non-linear equations that can be solvedas described above using the Newton-Raphson algorithm or other methodsknown in the art. Given a numerical estimate of the probability of anexecution, MPs in the dissemination list are ranked by placing the onewith the greatest probability of execution on top of the list, then theone with the next greatest probability of execution in the second-rankedplace, etc.

A preferred system also monitors the price fluctuation following orderdelivery to a market center, and identifies any statisticallysignificant correlations between the order delivery event and subsequentprice fluctuation on the market, separating the three cases where theorder was executed in whole, executed in part, or rejected. Thisinformation is then taken into account in creating a rankeddissemination list, to avoid sending the order to MPs that have apattern of trading ahead of a large order or leaking information thatwould allow others to do so, in both cases causing significant adversemarket impact.

In a preferred implementation, users are allowed to specify thealgorithm that seeks to detect MPs that cause adverse market impact andinsert this into their request to create the dissemination list. Forexample, a user may first query the database for the list of MPs thatpermit access to their past behavior data. Where such data confirms thatthey have not been associated with a statistically-significant adversemarket impact in the past, the user can then create a finaldissemination list from a CTI database query that restricts the searchto the MPs from the good behavior list. For example, the query mightseek the 10 biggest buyers among the MPs that do not have adverse marketimpact. In another example the CTI query would be executed withoutconsideration of good behavior, but the ranking is modified using themarket impact information to lower the rank of MPs that have thestrongest correlation with adverse price movement. There are two caseswhere market impact can be relevant: when an MP rejects an order, andwhen the MP accepts the order but price subsequently moves in adirection that will make further orders more expensive to trade. Thelatter case is expected and is the normal reaction of the market to theremoval of liquidity on one side, but the effect can be exaggerated ifthe MP either leaks information or “rides along” with the institutionalclient, by taking a proprietary position in anticipation that theinstitutional client will continue to work the position on the market.In a preferred implementation, the average price impact of an orderdelivery to a specific MP is calculated separately for these two cases.If the party entering the order is placing a single order, then the onlyrelevant market impact is that which occurs when the MP does not executethe order. But when the order entry party intends to continue to workthe position, the relevant market impact is the weighted (by theprobability of execution) average of the market impact when the order isor is not executed, as calculated above.

A further embodiment shown in FIG. 7 is directed to ranking CTI queries.This embodiment provides a service that derives from the CTInotification system discussed above. Dissemination lists are createdfrom queries in the CTI information database, as for example whensearching for the largest buyers of DELL in the past 40 minutes. Thepreferred system stores these lists at step 710 and at step 720calculates success rates for CTI notifications based on standardqueries. At step 730, for a given query, the system reports to a user onthe relevant statistics. For example, a user planning to launch a CTInotification to sell 10,000 shares of DELL to the 10 largest DELL buyersduring the past T minutes could view the success rate of this type ofquery in the past for time windows of T=10, 20, or 40 minutes. This willallow users to optimize the choice of time window: if the time is tooshort, the 10 largest buyers might include some small traders; if it istoo long, it might include large buyers who are no longer activelybuying the stock.

A further embodiment looks not only at the probability of execution butthe average and root mean square of the price fluctuation in atwo-minute period following the CTI notification and at step 740 reportsthis information to a user posting a similar query. CTI queries thatlead to excessively large dissemination lists, or dissemination liststhat include front runners more than natural contras, will be associatedwith statistically significant price impact.

SelectNet embodiment: an alternate embodiment of the subject inventionenables the deployment of the order routing and targeted notificationsystem within existing communication and trade execution mechanisms ofan exchange or ECN. Although the description below refers to the NasdaqSelectNet system it will be apparent to those skilled in the art thatthe same invention can be deployed in other exchanges, markets or ECNswith appropriate changes in the communication protocols. SelectNetallows Nasdaq Market Participants (sell-side firms) to route orders toother market participants or “MPIDs” via so-called “preferenced” orders.In the SelectNet embodiment the system has a separate MPID. When a usersends a preferenced order to this MPID, the system will execute a queryagainst a confidential database, as described previously, to determinewhich other MPID is most likely to take the contra to that order. Itthen issues a new preferenced SelectNet order to this second MPID. Forillustration purposes we will assume that the originating party's MPIDis AAAA, the system is given the MPID SSSS and the target's MPID isBBBB. The first participant (AAAA) will issue an order preferenced toSSSS, following which SSSS executes a query against the CTI informationdatabase and determines that the optimum recipient for this order isBBBB. SSSS then issues a preferenced order to BBBB. If BBBB chooses toaccept (execute) this order, SSSS in turn attempts to execute the orderentered by AAAA. When both orders have been successfully executed, thesystem (SSSS) issues a message containing the details of the trade suchas price, side of each party, etc. This message locks in the trade andtriggers the clearing process. In this embodiment there is a possibilityof a race condition wherein AAAA had issued a cancel request message atthe same time that BBBB had executed the order. This creates apossibility of SSSS being left with a liability with BBBB that does notmatch a negating liability with AAAA, so the execution from BBBB cannotbe processed until the market has been successfully notified that AAAA'sorder is matched and not cancelable. This new difficulty arises becausea market negotiation system (in this case SelectNet) normally does notcontemplate the possibility of an intermediary entering an order onbehalf of another party where said intermediary does not acceptliability for the order. The normal workflow of a market is one whereina party entering an order is liable for the order, independently ofwhether another order has been previously entered by another party(here, AAAA). To link the two legs of the trade into a singletransaction, the market systems must be modified so that messages thatwould lead to processing of the first leg of the trade are suppresseduntil the second leg of the trade can be executed. An enabling solutionis described next. Preferably, the market's normal processing ismodified so that the first execution message received from BBBB does nottrigger an execution confirm message back to BBBB or the correspondingclearing report that would otherwise have locked in that trade forclearing. Instead, only the execution message notifying SSSS of theexecution by BBBB is allowed to proceed. SSSS then executes theoriginator's order, whereupon once again the market system modificationsuppresses notification of the execution to AAAA and clearing, leavingonly the execution confirm message back to SSSS. At this point neitherAAAA or BBBB are able to cancel their orders, since both have beenexecuted as far as the market system is concerned. Upon receipt of thesecond execution SSSS triggers a trade report that locks in the tradefor clearing purposes. Preferably, the anonymity is maintainedpermanently by having SSSS intermediate the transaction in the same wayas an agency broker would intermediate a transaction between two otherbrokers without the benefit of a spread. So both AAAA and BBBB aretrading with SSSS, and the trade will clear as two trades where SSSS'sclearing responsibilities net to zero.

In an alternate embodiment, SSSS is not a central counterparty but theclearing processes are modified to maintain anonymity until the end ofthe day or some other specified future time, by masking the counterpartyfield in all messages to the participants and their clearing firms. In afurther alternate embodiment the preferenced order still appears as anorder from SSSS so that the recipient does not know that it came fromAAAA, but anonymity is not imposed after the trade and both partiesdiscover whom they traded with immediately after an execution. In yetanother alternate embodiment the targeted preferenced order to BBBBdisplays the originator's MPID, in which case the system is in effect atargeted quotation system allowing Nasdaq Market Participants to quotemore aggressively than they would be able to on an open system, bytargeting said aggressive quote to parties they believe are more likelyto trade than to front run on their trading interest information. In allof these embodiments, an optional message field available for traders tocomment their orders can be used to specify dissemination parametersthat differ from a default routing system. Preferably, the defaultrouting will look for the most recent net buyer or seller of at least asmany shares as in the originator's order (if the originator's order isto sell 2000 shares, for example, the system will look for the mostrecent net buyer of 2000 shares).

In an alternate embodiment, a lower bound is set on the query size sothat smaller orders do not end up being targeted at random to the mostrecent execution, but instead accurately target a party interested inaccumulating the security. For example, a minimal query size of 5000shares is generally sufficient to select out Market Makers with randomfluctuations in their inventory. In this case, a 2000-share order wouldbe routed to the most recent buyer of 5000 shares, while a 10,000-shareorder would be routed to the most recent net buyer of 10,000 shares. Theuser is able to reduce this default query size by inserting a key andparameter in the message field on the order. For example, the threecharacters Q3M indicate that the query should look for the most recentbuyer (or seller) of at least 3,000 shares. Another use of the messagefield associated with an order is as follows. An order for 20,000 shareswith the key “D10M” in the text message field would indicate that SSSSshould route an order preferenced to the optimal target for 10,000shares, instead of 20,000. The recipient (BBBB) can counter with agreater size that would execute against the originator's order (forexample, 25,000 shares) and may get an execution back for more than thesize of the SSSS-to-BBBB order. Although this functionality may appearsimilar from the user's perspective to the reserve size orders that ECNsmake available, the ECN implementation of reserve size does not enableits implementation within an order routing facility such as Nasdaq'sSelectNet where the an order is delivered for execution and is not heldin a “matching book.”

In a further enhancement, the originator can also enter the charactersN3 indicating that the order should be routed not to one, but to threemost likely contras (three most recent net buyers or sellers of at leastas many shares as in the recipient's order). In this case, it ispossible that multiple contras will respond to the order, and the sum ofrouted orders can comprise more shares than the originating order. Whenthe whole size of the originating order has been consumed, the remainingrecipient orders are canceled. If the last execution would overdraw theavailable size, then the execution size will be reduced to that whichcompletely fills the originating order. When there is residual size froma counter or a multi-party execution the system generates a new order toAAAA, which appears as a new originating order from BBBB routed throughSSSS.

In an alternate embodiment, the excess size of BBBB's order is simplydeclined. In the event of a race condition where the recipient hadexecuted the order at about the same time as the cancel message was sentout, the execution is rejected. Another option lets users enter thecharacters “*69” in the message field, in which case the order will berouted to the most recent contraparty in an executed trade with theoriginator. This allows one to continue working an order anonymouslywith the same counterparty, rather than implementing a new databasequery and risking notifying multiple parties of the trading interest.Another option permits the users to enter the characters “$02”indicating that the price to be delivered to BBBB should be $0.02 lessaggressive than the price of AAAA's order. When this feature is used,BBBB is expected to respond with a counter for a possibly differentprice. SSSS will then compare the counter price to AAAA's entered priceand execute both orders at the counter price if the orders match.

In the preferred SelectNet embodiment, the message field entered by theoriginator is stripped out of the order sent to BBBB, so that BBBBcannot see the dissemination parameters used. In an alternateembodiment, the order to BBBB contains only those parts of the messagefield that are recognized as valid dissemination instructions, exceptthe number following the $ sign in the case of price discretion orders.In a further alternate embodiment, the entire message field entered bythe originator is forwarded to BBBB. Note that this embodiment is notconsistent with enforcing anonymity since the originator may then chooseto display his MPID in the message field.

In an alternate embodiment of the SelectNet implementation, the systemis a midpoint execution system recognized as such through its MPID,which for illustration purposes we will take to be MMMM instead of SSSS.In contrast to the above description, the system will generally notexecute at the price entered by either party. Instead, all parties arepreviously informed that MMMM will only execute orders at the midpointprice. The originator is therefore comfortable to send in an aggressiveprice, knowing that it will be interpreted as a cap on how far themidpoint price may drift, beyond which he would no longer be interestedin carrying on with the trade. MMMM receives the originator order,executes a query as above to determine the most likely contra(s), andsends a preferenced order to the target (BBBB). In contrast to theprevious embodiment, however, the price of the order to BBBB is not thesame as the price cap on the originator's order. Instead, the order toBBBB is priced passively (less aggressive than the midpoint price; BBBBcan accept the order at this price (which is an aggressive price fromBBBB's perspective) knowing that this new price will be considered onlyas a limit on how far the midpoint is allowed to drift before BBBBceases to be interested in completing the midpoint trade.

Upon receiving the execution from BBBB, MMMM corrects the price to thecurrent midpoint and awards both the originator and the recipient priceimprovement over their stated limits. In doing so, MMMM is modifying theprice on BBBB's execution of the order. This is possible because, asabove, BBBB's execution is not locked-in until it has been confirmed bythe market system. In the present embodiment, the confirmation of BBBB'sexecution is suppressed and instead a later execution message is sent toBBBB with the better price. Since the execution message coming from themarket is the legally binding version of the trade, BBBB's systems areset up to key off the fields in this latter execution message, andtherefore will incorporate the improved price in its P&L sheets, as wellas in clearing support systems. Although the SelectNet embodiment isdescribed in terms that enable its implementation in the Nasdaq StockMarket, it will be clear to those skilled in the art that the samesystems and methods can be deployed in other exchanges with electronicorder routing and display, via adaptation to the appropriate messagingprotocols.

The existence of the market-deployed embodiment enables an importantenhancement of the auction server embodiment of the subject invention.In this enhanced version of the auction server, users enterdissemination parameters indicating that they would like to drawresponse orders from sell-side firms (such as Nasdaq MarketParticipants). A user specifies the parameters mentioned above for theSelectNet embodiment, including the number of sell-side firms to betargeted, the displayed quantity, “*69,” and other above-mentionedoptions. The auction system will then route preferenced orders to SSSSwith a very passive price, such as $0.01 for a buy order, indicatingthat a counter-offer is expected. This very passive targeted order is ineffect a targeted “Request For Quote” (RFQ) announcing the initiator'sauction. In this case, the originator of the SelectNet preferencedorder, AAAA, is the market participant hosting the auction. Throughmarketing means, AAAA will let it be known that orders for thisspecified very passive price should be handled by sending a newpreferenced order to AAAA containing BBBB's true limit price, as if thiswere the response order into the auction hosted by AAAA. If this neworder matches the initiator's conditions, AAAA will execute the neworder coming through the market system. In an alternate embodiment, themarket system is used only to issue the RFQ and the recipient canrespond through a separate communication channel. In that case, thepurpose of the market system is to ensure that the RFQ is seen by thesell-side trader, since it will be displayed on a GUI which is generallyfound on every sell-side trader's desktop.

In a further alternate embodiment, a market participant enters either(1) a query request that is used by the system to compute adissemination list, or (2) order parameters from which a disseminationlist is calculated by the system based on ranking likely contras byprobability of execution. But in this embodiment, in contrast to thosedescribed above, the resulting dissemination list is sent to anon-system entity responsible for sending messages to the members of thelist (as opposed to having the messages sent by the system of thepresent invention). The non-system entity is preferably contractuallybound to respect the confidentiality of the dissemination list, and touse the contents of the list only for the purpose of sending informationto members of the list. As above, the sent information may includeorders, or information about orders.

In a further alternate embodiment, the dissemination list is sent to thesame party who entered the query request (or the data from which thedissemination list was calculated). In a still further alternateembodiment, the contractual agreement (to use the dissemination list forno other purpose than to send its members information) is supplementedby a system certification process wherein a jointly-chosen consultingfirm analyzes the software system used by the party receiving thedissemination lists, to certify that the software system maintains theconfidentiality of the lists received and uses the lists only for thepurpose of sending securities-related information to members of thelists.

In a further alternate embodiment, the contract further imposes anauditing procedure, wherein a mutually-agreed-upon auditing firmcertifies that the party receiving the dissemination lists hasmaintained the confidentiality of information therein and used it onlyfor the intended purpose.

A further embodiment comprises a depository of orders that can be pulledby any matching system. Orders placed here are dormant but any thirdparty with execution authority can draw from this liquidity pool. Thisis particularly valuable in a world that features an increasing numberof auction systems: Optimark, POSIT, AZX, eVWAP, and others that servicea growing number of call auctions. In call auction trading, customerorders for a stock are batched together and executed in multilateraltrades at specific points in time when the market for the stock is“called.” This contrasts with continuous market trading where atransaction is made any time a buy and a sell order meet in price duringthe trading day. Recent advances in computer technology haveconsiderably expanded call auction functionality.

Different auctions execute at different times, which are often notpublicly known (for example, POSIT has a 5-minute fuzzed match), makingit very difficult indeed for a trader to know where to place an order.This fragmentation problem is far worse than the corresponding problemin continuous markets, since there is fragmentation in time as well asin space.

The order depository embodiment allows participating auction systems topull eligible orders from this liquidity pool, thereby eliminating thefragmentation problem for multiple call auctions. A preferred method isdepicted in FIG. 8. At step 810, a preferred system receives datacomprising an order from a first MP, and at step 820 the received datais stored in a database. At step 830 the system receives data comprisingconditions on orders from a second MP (e.g., a participating third partyauction system). At step 840 the system searches the database for ordersthat satisfy the conditions received from the second MP, and finds acollection of one or more orders (“found orders”) comprising the orderreceived from the first MP. When such orders are found, they aredesignated, at step 850, as “reserved.” At step 860 one or more of thefound orders (the orders found in the database that satisfy conditionsreceived from the second MP) (including the order received from thefirst MP) are routed to the second MP.

At step 870 the system receives data from the second MP regarding thestatus of the order from the first MP that was routed to the second MP.If at step 880 the received status data indicates that the order wasexecuted, then at step 885 the system reports the execution to the firstMP. If at step 880 the data does not indicate that the order wasexecuted, then the system checks at step 890 whether the data indicatesthat the order was released. If so, then at step 895 the released orderis un-reserved (the “reserved” designation is removed).

An alternate embodiment does not rely on third party auction systems topull orders from the depository, but instead actively routes the ordersout to such systems for a possible match. When the choice of destinationis based on CTI information, this is an example of the order routingembodiment described above. Another situation arises when call auctionsdo not publicly release the precise timing of a call, in order to reducethe potential for gaming opportunities. For example ITG's POSIT runsmidpoint matches with a fuzzed call time; the uncertain time of the callreduces the temptation to game the system by placing, for example, alarge sell order and then buying up the market immediately prior to amatch, in order to move the midpoint price up and get a better price onthe sell order in the event of a fill. With an uncertain match time theMP would have to sustain buying during several minutes and risk havingpotential matching orders in POSIT get canceled. The uncertainty aboutthe matching time creates a problem for traders: they must either facethe multiple exposure problem when the same order is placed in varioussystems to increase the probability of a match, or commit the order to asingle system and risk missing an opportunity to trade in anothersystem. In this alternate embodiment, call auctions that do not publiclydisplay the time of a match submit this information confidentially tothe system, which then uses that information to reserve the orders fromthe order repository and route them to the call auction just prior to amatch. Because it knows the precise time of a call, the system does nothave to commit the order to the call auction for more time than isnecessary to check for a possible matching contra order. From theperspective of the auctioneer, the only effect of providing theconfidential information on the timing of a call is to attract moreexecutable orders.

Database queries: In a preferred embodiment, a CTI notification routertargets notifications of trading interests to likely contras byperforming queries in CTI information databases. The description belowdescribes preferred databases and preferred queries that effectivelyrank likely contras.

Trade Database: Who traded . . . against whom? Trades often originatefrom buy-side traders and are routed by a broker to a marketplace or ECNwhere they either execute or get routed to another execution destinationwhere a better price may be available. In this process of executing asingle trade, several intermediate reports are generated, neither ofwhich carries complete information on both the end-buyer and theend-seller's identity.

Automated Confirmation Transaction Services^(SM) (ACT^(SM)) datacontains mandatory trade reports for the tape, and clearing reports; theonly available information on the identity of the buyer and seller isthe Market Participant ID (MPID), a 4-letter symbol assigned to eachmember of the stock market.

An example helps to illustrate how ACT data can be used to reconstruct atrade: a private individual places an order to sell 500 shares of DELLthrough an order entry firm such as a discount broker, or through an ECNsuch as Archipelago (ARCA). This order will be routed to the marketcenter with the best bid at the time. Thus, ARCA may route the order toInstinet (INCA) for example. The contra order itself may belong to abuy-side firm such as Fidelity, and is presented on the market by aclearing broker, say Bear Stearns (BEST). Instinet would report a tradewhere INCA buys from ARCA, and another trade for the same amount whereINCA sells to BEST: these reports are issued for clearing purposes. ARCAwould internally effect a book entry for their customer and issue amandatory report to ACT as the selling broker. Internally, BEST takesnote of the transaction being executed for their customer Fidelity, andwill clear and settle the trade in Fidelity's name.

The ACT data in itself is incomplete in several ways: the identity ofthe end buyer and seller are not given in the ACT report, and one is notrequired to issue clearing reports immediately after the trade. Clearinginformation submitted through ACT, however, does allow one to identifywhich are the two sell-side participants (brokers) that mediated eachtrade as agent, or executed the trade for their own account.

Other sources of information besides ACT data can be used, such as tradereports by broker-dealers, from the buy-side clients themselves, or fromcommunication providers such as NYFIX that route orders. Information onthe identity of the end buyer/seller is available from any of thefollowing sources: (1) the broker or clearing firm which booked thetrade for its client; (2) the clients themselves; and (3) via thenetworks and software systems that “know” the end user's location andmessage routing instructions. Examples include order management systemsand trading systems such as ECNs, as well as auction server 60.

In general, the trade database will contain incomplete records of tradesand orders, and must be capable of receiving further information as itbecomes available to complete the records. A preferred embodiment isbuilt to function with an incomplete trade database.

A preferred system receives trade report data from the market (such asACT data) and, optionally, voluntary trade reports from brokers andclearing firms. When only the market data is received, the brokers willbe listed as parties to the trade. When the end user information isreceived (for example, from an auction server 60), this information isadded to the description of the trade.

Dealing with incomplete end-party identification: When the result of aCTI query is that a notification should be sent to an “MPID” (i.e., itis not possible to further refine the identity of the target), apreferred embodiment uses an organization-specific function to map thisMPID to a list of users. The system supports different possibilities.For example, a user representing a client firm could choose from thefollowing options:

-   1. Send to all users within the organization associated to this MPID    (for example, if the MPID is “MLCO,” then all Merrill Lynch traders    can view the notification).-   2. Do not notify.-   3. Send to a unique “wild card” user for re-distribution. For    example, this may be an Instinet router that can forward the message    to the appropriate terminal.-   4. Send to a list of users or accounts specified by the organization    (for example, MLCO may request that such notifications be sent to    their block desk but not to their proprietary trading desk).

When the result of a query is an account (i.e., an aggregate of usersthat share information and aggregate their trades on behalf of the sameaccount), the system will associate a list of users to this account. Inan alternate embodiment, there is a messaging destination such as a FIXmessage destination associated to each account. When messages are sentto users, the procedure is based on an account-specific function. Bydefault, all users at that account are targeted and no other usersreceive the notification, but other possibilities are supported as well.For example, it is possible to set up another account so that it alwaysreceives these notifications as well. An organization may specify thatall users within the organization should receive this notification. Orthe notification may be sent to a single user, or to no one at all.

Finally, queries may return individual users. In that case anaccount-specific function is used to determine who should be notified:this can be the user only, all users that trade for the same account,all users within the organization, or no user at all. The list is notintended to be exhaustive.

Trade data by type of contra: trades are preferably classified as beingagainst a member firm (when the contra party was a Nasdaq member firm),against a non-member (contra party was not a member firm), or a “cross”(when the broker reports a trade as a cross, or reports the tradeagainst a non-member as Agency). A seller would want to notify someonethat is likely to buy—that could be a buyer against other member firms,in which case the assumption is that this buyer is working an order andwill continue to do so, or a member firm selling to a non-member, whichindicates that the broker is taking over the position and will then turnto work it as Principal. Brokers that implemented a cross can be ofinterest to a buyer or to a seller, since this trader would be incontact with both buying and selling customers.

Queries by level of trader ID information: In database queries, thesystem will support queries that only look at trade data entries wherethe end user is known; or queries that consider only trade data wherethe end user is not known; or all data entries.

Accounts: Accounts represent information sharing pools: if one user isallowed to receive a notification then all users within that accountwould be allowed to receive the same notification. Trade data likewiseis attributed to accounts, so that database queries that look for the 10biggest buyers, for example, would aggregate the trades per account andseek the accounts with the greatest net number of shares bought. Whenthe end user is not known, the system assigns a default “star” accountrepresenting the sell-side organization brokering the trade. Queries canbe executed on accounts, in which case the result of a query is always alist of accounts.

Sources of trade information: Information on trades preferably comesfrom at least the following sources:

-   1. ACT trade reports that get forwarded to the NSCC.-   2. Auction Server trade reports: Includes the system user ID    (specific to a particular terminal) on both sides of the trade, on    top of the two relevant MPIDs.-   3. Broker-dealer trade reports: Participating Broker-dealers are    able to associate the end user ID to their side of a trade as a    service to their buy-side customers, who can then register to    receive CTI Notifications.

Aggregating buy-side trading data. In an alternate embodiment,Broker-dealers are allowed to use a code name in lieu of the true clientname when they provide data on trades they executed on behalf of theirbuy-side clients. This trading data would then let their customersattract notifications specifically from the trades they executed withthat specific broker, not counting any trades executed through otherbrokers and that would be contributed to the trade database underdifferent coded names. In this model there is an incentive for thebuy-side client to focus their trading activity with a single broker andthereby place a stronger bid for the right to receive notifications. Inan extension of this embodiment of the subject invention, the systemoffers brokers a service whereby each participating broker can agree todisclose the mapping between the coded client name and the correspondingactual client ID. In return, the participating brokers receive thenotifications sent to the buy-side client firm identified by a query onbuy-side aggregate trading. The following example helps to understandhow this works. Mutual Fund A is working an order to buy through 8different brokers to minimize market impact, sending 10,000 sharesthrough each broker; Mutual Fund B wants to sell a large block of stockand submits dissemination parameters to notify the biggest buyer'sbrokers. Three of the eight brokers have disclosed the true client ID,so the query will return Mutual Fund A with 30,000 shares done and fivedifferent coded IDs with 10,000 each, in the absence of other relevantdata. Mutual Fund A is thus identified as the largest buyer, and thethree participating brokers (those who have disclosed Mutual Fund A asthe client) receive the notification of the large block on the contraside and can call their client for more.

In an alternate embodiment, the situation wherein multiple brokersprovide information on the same client is resolved using a“winner-take-all” approach, where the notification is sent only to thebroker that provided the largest amount of information (such as thelargest net sum of shares traded by their client) as opposed to sendingit to all brokers having provided information that was part of theaggregation. In a further alternate embodiment, the broker enablingaggregation by releasing the true identity of the client will specifywhether he is willing to share the receipt of notification with otherbrokers. Once the aggregation is performed and the target client isidentified, a broker who is not willing to share notification withothers will be the only recipient of a notification if in fact thisbroker is the largest contributor of data, and is larger than theaggregate group of sharing brokers. If this is not the case, he will notbe notified and the sharing parties or single largest non-sharing brokerwill be notified instead. This embodiment enables participation by largeand small brokers within the same system without creating asystem-enforced bias that would either give smaller players equal accessto the large broker's clients or, on the other hand, lock in the largebroker's existing dominant position and not permit entry by smallerplayers willing to pool their data.

In an alternate embodiment of the notification mechanism, the brokersproviding data also enable blind pass-through of the notificationmessage itself. In this embodiment, the system uses encryptiontechniques that are known in the art to ensure to the originator of CTInotifications that only the intended recipient (buy-side client of thebroker, not the brokerage itself) will be able to see the content ofsaid CTI notification message. In the blind pass-through embodiment, thecontractual terms ensure that the broker is rewarded for participationthrough sharing the commission on the trade. In the case where multiplebrokers have provided data relevant to targeting the same client, thebroker's share of the commission revenue for the trade is an equalproportion of the total commission on the order, or a lesser amount ifthe corresponding proportion of the executed size were less than theamount of data provided in earning the right to notify the client. Forexample, the order was executed for 15,000 shares and three brokers hadcontributed data that helped identify the counterparty as follows:broker A had previously bought 3000 shares on behalf of the recipient,broker B had bought 22,000 shares and C had previously bought 15,000shares all on behalf of this same recipient. Broker A would get thecommission corresponding to 3,000 shares, while brokers B and C wouldget a third of the total or the commission equivalent to 5,000 shareseach. If the execution was instead for 1 million shares, then the threebrokers would get the commission corresponding to 3,000, 22,000 and15,000 shares, respectively. If the amount of data contributed isnegligible as compared to the size of a trade, then it is reasonable toaffirm that the data was not the chief factor in enabling the trade.Other billing methods that adequately reward the data providers andencourage their participation will be apparent to those skilled in theart.

In an alternate embodiment of the multiple broker notification, theoriginating user specifies in the dissemination parameters theconditions that brokers must satisfy in order to receive a notificationmessage, in the event that multiple brokers were contributing aggregateddata. For example, the user will provide a list of brokers that areeligible for notification (the originator will know with which brokersthey have been working the order, but may wish to notify only one or asubset of them). In an alternate embodiment the user enters a conditionon the amount of trading data provided—for example, by specifying that(when data from multiple brokers was aggregated) only brokers havingcontributed a net size of at least 10,000 shares should be notified.

The following table describes structure of a preferred trade database:

Trade database specifications: Required/op- Field name Comments tionalType MPID Required. This is the executing party, Required Char[4] notthe service bureau. Username System username is available on allOptional Char string system trades. This party is the seller, the contrawill be the buyer. Account Available for Transaction Server OptionalChar string trades Client name Buy-side client firm, or “blank” if it isOptional Char string not a buy-side account. Blind pass-through “Y” or“N”. Needed to support Optional Char queries on buy-side accounts onlyDissemination list ID For transactions that follow Optional Char stringnotification requests, this will be the dissemination list ID. Otherwiseit will be blank. Query Eligible Boolean. Specifies if this trade can beRequired Boolean counted in queries. Default is “Y”, but there arespecial cases where a user would want a trade not to attractnotifications. This information will come via Transaction Server. ContraType Member (M), Non-member (“N”) or Required Char Crossed (“X”) ContraMPID Required. This is the true contra Required Char[4] party, not theservice bureau. Symbol Required Char[4,5] Quantity (shares) Required INTPrice Nominal, USD Required Float Trade reference number Issued by ACTRequired Char string Branch Sequence Issued by the reporting partyOptional Char string number Execution time Required INT Reporting timeRequired INT Reporting Capacity Principal, Agent Required Char Media Canbe “N” (not reportable) or “R” Required Char (report to media/tape). ACTStatus Refers to the status of the trade in Required Char ACT. A =Accepted B = Broken (Previously locked-in trade) C = Canceled D =Declined E = Error F = Forced match; locked-in trade G = One-sidedsubmission (give-up lock-in: reports trade against ACT inactiveparticipant) I = Inhibited (by clearing firm) K = Rejected sizeabletrade L = Automatic locked-in trade at end of T + 1 M = Matched;locked-in by ACT N = No/Was trade (trade did not occur) R = Locked-intrade; rec'd via execution system interface and locked-in by QualifiedSpecial Representative (QSR) or by Nasdaq S = Automatic locked-in splittrade at the end of T + 1 T = Trade reporting only and not for clearingsubmission Note: these are the end-results of the ACT processing. Apreferred embodiment subscribes to real-time updates, so temporary ACTstatus entries should be recognized as well. Source “M” and “N” are ACTreports by Required Char member firms. “O” is SelectNet, “S” is SOES,“A” is ACES, “C” is CAES, “I” is ITS, “F” is Optimark, “U” is UTP. QSRClearing flag: “Q” will not clear Required Char through ACT, “Z” willclear through ACT, “N” ticker only, “L” is locked in will clear throughACT, “ ” (space) will match and clear through ACT. As-of Boolean, “Yes”when the trade was Required Boolean executed after hours the previousday and is therefore being reported late and should not be printed onthe tape. PRINC_MKT_PART “Y”, except for ECNs and Required Char stringChicago/other marketplaces where it takes value “N”.Trade Database Queries

In a preferred embodiment, the system offers users simple forms toassist users in the task of creating useful queries. In the followingexamples, the user is trying to sell a block; the forms are designed toidentify potential buyers. The reader skilled in the art will easilydiscern how these forms should be modified when the user is trying tobuy a block rather than to sell.

Counting notification targets: One of the key concerns in institutionaltrading is controlling the number of parties that are notified of theinstitution's trading interest. Another is to try to notify naturalcontras, rather than traders that would be more likely to trade on theinformation or share it with others.

To control the number of parties targeted, a preferred embodimentsupports queries that rank likely contras and send notifications only tothe top N targets. Such queries give the user complete control over thenumber of parties targeted as well as the conditions that they mustsatisfy in order to be included in the dissemination list.

To count targets, a preferred system keeps track of which userscurrently have an open push channel (such as a TCP connection) or areotherwise reachable via communication channels that support alertdelivery (such as a pager). Users can also choose to receive alerts viaemail. In this last case the system preferably verifies that the user ispaying attention to the channel by requesting a receipt and monitoringthat the user sends the receipt back within a few seconds. Only usersthat have an open session or a valid alert channel can be members of aranked dissemination list. Queries exclude all data entries attributedto users, accounts, or MPIDs that are not reachable; an account or MPIDis “not reachable” if it contains no reachable user.

Described next are some of the trade database queries that are offeredto users at the graphic user interface level; these should be viewed asexamples and not as an exhaustive list.

1) Basic Notification: 10 biggest contras (buyers against member firms):This basic notification window offers a simple CTI query to identifypotential block buyers. This query uses ACT data to identify the N (10by default) MPIDs that have purchased the largest number of shares net(bought minus sold) from other member firms through trades of at least Xshares (1100 by default), in the course of the last Y minutes (30minutes by default). This indicates that they are working a customerorder or building up a position and are likely to continue to accumulatestock in the near future. Settable parameters include: (1) Maximumnumber of parties targeted: rank the biggest buyers and notify the top10 if there are at least 10 that fit the user's criteria; Time: counttrades during the past N minutes (default is 30 minutes)—differentdefault values for different symbols are supported; and (3) Size: countonly trades larger or equal to this size (default is 1100shares)—different default values for different symbols are supported.Alternate query: count total buys (gross amount bought) withoutsubtracting out sells.

A user can further refine the above basic query by specifying that thecontra-party must be within a list of MPIDs. For example, a user maytarget buyers that trade on ECNs, by listing all their MPIDs—orspecifically target Instinet traders only, using a query for buyersagainst INCA.

In another refinement of the same query, the user can request that thequery should consider (or not) any buyer based on price aggression,comparing the price to the national market best bid and best offer atthe time of the trade. Price aggression can be categorized as passive(for buys at the bid or below), neutral, or aggressive (buys at the askor higher).

2) Block desk query: 3 biggest sellers to non-members: this notificationwindow offers a query that identifies block desks that have taken alarge position over from a buy-side client. This type of trade isreported to ACT as an MPID trading as Principal against “blank”: nocontra party MPID is mentioned in the ACT report, and the broker istrading for his own account (not as Agency for another client).Broker-dealers that take over large blocks from institutional customerswill often turn to the markets to recover at least part of the position.For example, a block desk that sells a block to an institutional clientwill want to buy on the market and on ECNs to rebuild the position. So aseller would like to target block desks that have recently sold a largeblock to a non-member firm and would be looking to buy. From the pointof view of the block desk trader, he reports the trade to ACT andimmediately begins to see notifications from users with a contra-sideinterest; this makes his work easy.

The query uses ACT data or broker-dealer voluntary trade reports (whichcan be verified a posteriori using ACT data) to identify the N (10 bydefault) MPIDs that have sold the largest total number of shares throughtrades of at least X shares (10,000 shares by default) againstnon-members during the last Y minutes (60 minutes by default). Settableparameters include: (1) Maximum number of parties targeted: rank thebiggest sellers and notify the top 3 if there are at least 3 that fitthe user's criteria; (2) Time: count trades during the past N minutes(default is 60 minutes); and (3) Size: count only trades larger or equalto this size (default is 10M).

3) Graphic trade selector: allows users to view trade and bid-ask datain a histogram-style representation of the tape, where each trade isrepresented as a vertical bar whose height is proportional to the sizeof the trade (number of shares on the vertical axis) and is colored blue(for example) when the trade is at the ask or above, red (for example)when it is at the bid or below, and black (for example) when the tradewas inside the bid-ask spread. The color-coding lets the user easilyidentify and select aggressive buyers (the buyer behind a tall blueline) or aggressive sellers (tall red lines), and query the CTI databaseto send a notification specifically to the corresponding traders.

To use this feature, the user scrolls with a mouse over the graph. Whenthe mouse cursor passes over a circular activation region centered atthe tip of a bar (trade) the histogram bar becomes thicker, indicatingthat the trade can be selected by clicking. When the user clicks on abar, a short description of the selected trade appears in a text boxnext to the graph. For example:

-   “12:31 buyer 5300@45⅛=ask”-   “12:35 buyer 2700@44⅞=midpoint”

The system receives the time, size, and symbol and queries the databaseto find the identity of the buyer and seller behind the trade.

The query will look for both buyers and sellers, but keep the buyer ifit is a member firm reporting against another member firm, the seller ifit is a member firm reporting a trade with a non-member, and whicheverparty reported the trade if it was a cross. Alternatively, the user canchoose to not notify anyone if it was a cross, or to issue thenotification only if the trade was in either one of the threecategories.

4) Large block buyer from member firm: sends the notification to anyuser that has purchased a block of at least X shares in the course ofthe past N minutes. Fields to be entered by the user are: (1) Time:count trades during the past N minutes (default is 60 minutes); (2)Size: order size should be at least this large (default value is 10,000shares); and (3) Minimum price aggression: a drop menu allows the userto select among three options: consider all buys, buys above the bid, oraggressive buys only (ask or better) (default is above the bid). Asimilar query identifies large block sellers to non-members.

5) Repeat Buyers against member firms: targets users that have bought Xshares at least Y times during the past N minutes. Fields to be enteredby the user are: (1) Time: count trades during the past N minutes(default is 60 minutes); (2) Size: trade size should be at least thislarge (default is 3,000 shares); (3) Number of trades: the trader shouldhave executed at least this many buys (default value for this field is2); and (4) Minimum price aggression: a drop menu allows the user toselect among three options: count all buys, buys above the bid, oraggressive buys only (ask or better) (default is above the bid).

By listing MPIDs that must be on the contra side, the user can furtherrefine this query, for example, to count only trades where the contraparty was one of the three largest ECNs. A similar query identifiesrepeat sellers to non-members.

6) Buyers against MPID list: targets MPIDs that have bought a total ofat least X shares from a list of contra-party MPIDs, during the past Nminutes. This could be a specific contra-party MPID, or a user-definedlist, or a system group such as ECNs. Fields to be entered by the userare: (1) Time: count trades during the past N minutes (default is 60minutes); (2) Size: trade size should be at least this large (default is3,000 shares); (3) Minimum price aggression: a drop menu allows the userto select among three options: count all buys, buys above the bid, oraggressive buys only (ask or better) (default is above the bid); and (4)List of MPIDs: this may be a single MPID, a system group, or a listentered by the user.

7) Auto-ex imbalance: this query will target MPIDs that are MarketMakers and have been selling at the ask more than they've been buying atthe bid, counting only executions when the MM was not at the inside, butcounting out MPIDs that have sold a block during the same time period.Fields to be entered by the user are: (1) Time: count trades during thepast N minutes (default is 20 minutes); (2) Net size sold: net tradedsize (sells minus buys) should be at least as large as Size (defaultvalue for this field is 20,000 shares).

Queries on Orders

Data on open orders are provided by a trade execution facility (such asNasdaq SuperMontage or SelectNet), by a broker-dealer or ECN, or bytraders. Traders can provide data manually or via their order managementsystems; in those cases the system monitors the accuracy of the data aposteriori when respondents try to execute the order, and filter outtrade entry reports from traders that have reported inaccurately in therecent past.

1) 10 most aggressive orders to buy: this query will allow a seller tonotify the 10 users with the most aggressive open buy orders at least aslarge as a seller-specified SIZE. Orders will be ranked by aggressionusing an algorithm that takes into account price, size and minimumquantity. The default algorithm is as follows: first filter out ordersthat are smaller than SIZE, then rank all orders by price, size (largestsize gets top ranking) and minimum quantity (smallest minimum quantityis ranked higher than a large minimum quantity). Ties are broken by timeof entry, or by random ordering using random number generators that arewell known in the art. Alternate algorithms may later be offered, suchas ranking by time of execution. Fields entered by the user are: (1)Size: order size should be at least this large (default is 5,000shares); and (2) Min Quantity: if this box is checked, the query willcount only orders with minimum quantity less than or equal to thisquantity (default setting is 10,000 shares).

2) Unfilled trading interest: this query identifies users of thepreferred system that have initiated a CTI notification to buy thatexpired without having been canceled by the initiator, and where theaccompanying order was not completely filled, and that have responded toa CTI notification with an order to buy.

Parameters for this query are: (1) Maximum number of parties targeted:rank the biggest buyers and notify the top 10 if there are at least 10that fit the user's criteria; (2) Time: count the orders that expiredduring the past N minutes (default is 60 minutes); (3) Size: count onlyorders larger or equal to this size (default is 10,000 shares); and (4)Min Quantity: count only orders with a min quantity less than this size(default is 10,000 shares).

*69 functionality: Users of a preferred embodiment can delivernotifications to users that have traded with them on an Auction Server,or users who sent them CTI notifications. A graphic user interface 900(see FIG. 9) preferably provides a list of trades and notifications withcheckboxes 910 that the user can “click” to select notification targets.Sorting by time, size, and symbol is available. The system makes adefault selection by choosing all contra parties for the day's tradingactivity. The left part 920 of the screen represents CTI Notificationsreceived in the past; the right part 930 of the screen contains a listof executions. The user clicks on check-boxes 910 to select the targetsto which a new notification should be sent.

In a further alternate embodiment of the subject invention, the systemis an enhancement of an electronic trading system such as an ECN. Inthis embodiment, he system enables a user to request that a notificationof the user's order be directed to any party who enters an order on thecontra side when that second order is within a given price or sizedifference from the first order. Preferably, both orders are eithercompletely confidential or contain a large reserve quantity that was notdisplayed to the market, so that the two parties would otherwise neverhave discovered that they were very close to matching a large hiddensize. In this embodiment, if both parties have requested that theirorder be advertised to near-matching contras, as described above, thenan order notification is delivered to the second party entering theorder, but not to the first, so that the system functions in the sameway as if the second participant had not requested that his order beadvertised to near matching contras. In an alternate embodiment, bothparties would, in that case, be notified of the existence of thenear-match with another party's order, and both may come back with abetter counteroffer to close the gap and thus enable the trade to takeplace.

In a distributed implementation of this same embodiment a plurality ofECNs agree to cooperate on pooling their clients' trading interest inthe following manner: when one of the parties receives an order from acustomer and is unable to match that order internally, it willelectronically transmit the order to each of the other partiessequentially, using an ordering algorithm that maximizes the likelihoodof an early execution match, as is known in the art, but in each orderrouting event, if a matching contra is not found, but instead there is asecond participant confidential order that nearly matches the firstparticipant's order, then the ECN receiving the routed order will notifythe second participant of the existence of the near-match. The secondparticipant can then respond with a better price or size to close thetrade. Preferably, the first order that was not immediately matched isreturned to the first ECN and the second participant's subsequentresponse order is routed to this first ECN for matching. In an alternateembodiment, the first participant's order stays in the secondparticipating ECN for the specified “time in force” during which thesecond participant is able to respond. If the second participant doesnot respond within this time in force, the first order is returned tothe first ECN with unfilled order status. Preferably, in this“multiple-ECN model” the parties share commission revenues as they wouldin the case where the order were simply routed from the first ECN to thesecond for execution, so that the notification mechanism does not entailany change in billing but instead simply increases the frequency ofmatches. In an alternate embodiment, the party responding to anotification (second participant) agrees to pay a fee for removingliquidity when entering a response order, thereby creating additionalrevenue for the second participating ECN.

In these embodiments a computer system is installed at participatingECNs that receives data on the system's orders, stores said data, andenables queries against the order data to determine whether aparticipant's size and price difference conditions are met. The systemof this alternate embodiment also contains interfaces with eachparticipating ECN's existing system that enable it to deliver ordernotification messages to the ECN's customers. For example, for ECNs thatuse a FIX interface to their customers, the order notifications arepackaged as FIX IOI messages for routing by the ECN's FIX engine. In analternate embodiment the system maintains direct communications with theclient such as through a Web server, using methods known in the art as“push technology.”

Those of ordinary skill in the art will recognize that thecomputer-implemented system and method described herein provides atleast the following advantages:

(1) The system can calculate the total buying of potential contras bysumming the shares purchased or sold in a plurality of executions, butan initiating user cannot determine whether such multiple executionsoriginated from the same market participant.

(2) The system can receive dissemination parameters from an initiatingparty (such parameters as the minimum total number of shares that aparty should have bought or sold to receive the notification) and createa list based on these parameters containing zero, one, or severaldissemination targets—but the number of targets that satisfy theinitiator's dissemination parameters is not known to the initiator.

(3) Instead of an IOI, a message can be routed that comprises acertified trading interest. An example (described above in relation to apreferred embodiment) is a notification sent regarding an open orderthat can be automatically executed by responding to the notification, or(in an alternate preferred embodiment) a message that contains anexecutable order.

(4) The system preferably receives data from multiple broker-dealers,allowing the system to compare multiple records of the same trade to“net out” middlemen and identify the end buyer and seller. For example,if MP1 buys 1000 shares of DELL from MP2 on an ECN, the brokers on eachend of this trade will know only that they traded with this ECN. Butwhen each broker reports his information to the system, the system cancompare the two reports and identify the two end parties to the trade,enabling MP1 to subsequently negotiate a trade directly with MP2.

(5) The system can receive information on the buy-side origin of a tradefrom a plurality of broker-dealers. Thus, the system can reconstruct thecomplete trading activity of a buy-side party when that buy-side partyis working an order through a plurality of broker-dealers and/or ECNs.

All these are ways of using confidential information in win-winsituations, where the providers of information benefit by earning theright to attract more information or more order flow, for their ownaccount or for that of their clients. When the advantaged party is thedata provider's client(s), it is clear that a successful businessapplication will include a sharing of the benefits with the dataprovider to encourage participation.

FIGS. 10-20 show steps of method embodiments described herein.

FIG. 10 illustrates steps of a method of managing securities marketinformation. At step 110 securities order-related or trade-related dataregarding a set of securities market participants is electronicallyreceived. At step 1020 said received order-related or trade-related dataregarding said set of securities market participants is electronicallystored. At step 1030 a securities order-related or trade-related queryfrom a first securities market participant is electronically received.At step 1040, based on said order-related or trade-related queryreceived from said first securities market participant and on saidsecurities order-related or trade-related data regarding said set ofsecurities market participants, a dissemination list of securitiesmarket participants is computed. At step 1050, said dissemination listis transmitted to an entity who has been granted a privilege ofreceiving such lists in exchange for being contractually bound torespect confidentiality of the dissemination list and to use the listonly for the purpose of sending securities-related information tomembers of the list.

FIG. 11 depicts steps of another method of managing securities marketinformation. At step 1110, securities order- or trade-related dataregarding a set of securities market participants is electronicallyreceived. At step 1120, said received order-related data regarding saidset of securities market participants is electronically stored. At step1130, securities order parameters from a first securities marketparticipant is electronically received. At step 1140, based on saidsecurities order parameters received from said first securities marketparticipant and on said securities order- or trade-related dataregarding said set of securities market participants, a disseminationlist of securities market participants is computed based on rankinglikely contras by probability of execution. At step 1150, saiddissemination list is transmitted to an entity who has been granted aprivilege of receiving such lists in exchange for being contractuallybound to respect confidentiality of the dissemination list and to usethe list only for the purpose of sending securities-related informationto members of the list.

FIG. 12 depicts steps of a method of effecting a targeted auction. Atstep 1210, data including confidential information regarding marketparticipants is electronically received. At step 1220, said receiveddata regarding market participants is electronically stored. At step1230, information including a first order from a first marketparticipant computer is electronically received. At step 1240, saidinformation received from said first market participant computer iselectronically stored. At step 1250, a targeted dissemination list ofmarket participants is produced based on said stored data regardingmarket participants and said information received from said first marketparticipant computer. At step 1260, data based on said informationreceived from said first market participant computer is electronicallytransmitted to the market participants on said targeted disseminationlist. At step 1270, subsequent orders from market participants areelectronically received in response to said transmitted data. At step1280, an electronic auction is conducted among orders including saidorders received in response to said transmitted data; wherein in saidauction an order is displayed as a passive order and executesimmediately against contra orders at that price, but upgrades its priceto a more aggressive price for randomly-scheduled match check eventswhere neither party has control of time of execution. At step 1290, thestatuses of orders are electronically transmitted to the respectivemarket participants who initiated them.

FIG. 13 depicts steps of another method of effecting a targeted auction.At step 1310, data including confidential information regarding marketparticipants is electronically received. At step 1320, said receiveddata regarding market participants is electronically stored. At step1330, information including a first order from a first marketparticipant computer is electronically received. At step 1340, saidinformation received from said first market participant computer iselectronically stored. At step 1350, a targeted dissemination list ofmarket participants is produced based on said stored data regardingmarket participants and said information received from said first marketparticipant computer. At step 1360, data based on said informationreceived from said first market participant computer is electronicallytransmitted to the market participants on said targeted disseminationlist. At step 1370, subsequent orders from market participants areelectronically received in response to said transmitted data, whereinmarket participants have the option of placing an order in an orderdepository without initiating an auction or invoking targeteddissemination of data, said orders being dormant until an auction isinitiated in that stock. At step 1380, an electronic auction isconducted among orders including said orders received in response tosaid transmitted data. At step 1390, the statuses of orders areelectronically transmitted to the respective market participants whoinitiated them.

FIG. 14 depicts steps of a method of managing orders in a securitiesmarket. At step 1410, data comprising an order and conditions on saidorder from a first market participant is electronically received. Atstep 1420, said received data is electronically stored in a database. Atstep 1430, data comprising contra orders from other market participantsis electronically received and stored in said database. At step 1440,said database is searched for contra orders that satisfy said conditionson said order from said first market participant. At step 1450, contraorders that satisfy said conditions are ranked according to criteriacomprising said conditions. At step 1460, said order received from saidfirst market participant or portions thereof are routed to marketparticipants from which said ranked contra orders were received,according to ranking.

FIG. 15 depicts steps of another method of managing orders in asecurities market. At step 1510, data comprising a first preferencedorder and conditions thereon is electronically received from a firstmarket participant, wherein said first preferenced order is directed toa preferencing ID. At step 1520, said received data is electronicallystored in a database. At step 1530, data comprising contra orders fromother market participants is electronically received and stored in saiddatabase. At step 1540, said database is searched for contra orders thatsatisfy said conditions on said order from said first marketparticipant. At step 1550, market participants whose contra orderssatisfy said conditions are ranked. At step 1560, a second preferencedorder is sent to a second market participant with an optimum or optimalranking. At step 1570, if said second market participant accepts saidsecond preferenced order, an attempt is made to execute said firstpreferenced order and said second preferenced order as a singletransaction, where either both legs of the trade carry through tocompletion or neither does.

FIG. 16 depicts steps of a method of effecting a targeted auction. Atstep 1610, data including confidential information regarding marketparticipants is electronically received. At step 1620, said receiveddata regarding market participants is electronically stored. At step1630, information including a first order is electronically receivedfrom a first market participant computer. At step 1640, said informationreceived from said first market participant computer is electronicallystored. At step 1650, data based on said information received from saidfirst market participant computer is electronically transmitted toselected market participants. At step 1660, subsequent orders from saidselected market participants are electronically received in response tosaid transmitted data. At step 1670, an electronic auction is conductedamong orders including said orders received in response to saidtransmitted data; wherein in said electronic auction an order isdisplayed as a passive order and executes immediately against contraorders at that price, but upgrades its price to a more aggressive pricefor randomly-scheduled match check events where neither party hascontrol of time of execution. At step 1680, the statuses of orders areelectronically transmitted to the respective market participants whoinitiated them.

FIG. 17 depicts another method of order management. At step 1710, firstparticipant information from a first market participant computer iselectronically received, said first participant information including afirst order and indicating: (i) whether said first order is exposed torandom match check events; (ii) whether said first order is exposed toimmediate execution against orders entered independently on the contraside; and (iii) whether said first order is exposed to immediateexecution against orders entered in response to notification of saidfirst order. At step 1720, said first participant information iselectronically stored. At step 1730, a second order from a secondparticipant is electronically received. At step 1740, said second orderis executed against said first order if the price and size match and ifsaid first participant information indicates that said first order isexposed to immediate matching against incoming orders. At step 1750,randomly-timed match check events are executed, wherein other ordersmatch against the first order if the price and size match and if saidfirst participant information indicates that said first order is to beexposed to randomly-timed match check events.

FIG. 18 depicts another method of effecting a targeted auction. At step1805, data including confidential information regarding marketparticipants is electronically received. At step 1810, said receiveddata regarding market participants is electronically stored. At step1815, information including a first order from a first marketparticipant computer is electronically received. At step 1820, saidinformation received from said first market participant computer iselectronically stored. At step 1825, a targeted dissemination list ofmarket participants is produced based on said stored data regardingmarket participants and said information received from said first marketparticipant computer. At step 1830, data based on said informationreceived from said first market participant computer is electronicallytransmitted to the market participants on said targeted disseminationlist. At step 1835, an order from a second market participant iselectronically received. At step 1840, order parameters for possiblematching and execution of said second participant's order are checkedagainst said first order. At step 1845, an order from a third marketparticipant is electronically received in response to said transmitteddata. At step 1850, order parameters are checked for possible matchingand execution of said third participant's order against said firstorder. At step 1855, an electronic auction is conducted among ordersincluding said orders received in response to said transmitted data. Atstep 1860, the statuses of orders are electronically transmitted to therespective market participants who initiated them.

FIG. 19 depicts steps of another method of managing market information.At step 1910, data is electronically received from a first marketparticipant, said data comprising an order to buy or sell marketsecurities, and further comprising conditions on similar orders on thecontra side. At step 1920, said data from said first market participantis electronically stored. At step 1930, information is electronicallytransmitted to one or more entities, said information comprising saidconditions. At step 1940, notification from one of said one or moreentities is electronically received, said notification comprising anindication that a second participant's order matches said conditions. Atstep 1950, information including data related to said order receivedfrom said first market participant is electronically transmitted to saidone of said one or more entities.

FIG. 20 depicts steps of another method of managing market information.At step 2010, data is electronically received from a first marketparticipant, said data comprising an order to buy or sell marketsecurities and data specifying order-handling rules that specify thatthe order should be exposed to randomly-scheduled match-check events. Atstep 2020, said data from said first market participant iselectronically stored. At step 2030, information from a second marketparticipant is electronically received, said information including anorder to trade securities. At step 2040, a match-check event iselectronically scheduled. At step 2050, execution of auctions withorders received at the time of said scheduled match-check event iselectronically triggered.

While the embodiments shown and described herein are fully capable ofachieving the objects of the subject invention, it is evident thatnumerous alternatives, modifications, and variations will be apparent tothose skilled in the art in light of the foregoing description. Thesealternatives, modifications, and variations are within the scope of thesubject invention, and it is to be understood that the embodimentsdescribed herein are shown only for the purpose of illustration and notfor the purpose of limitation.

What is claimed is:
 1. A method of managing orders in a financialsecurities market, comprising the steps of: (a) electronically receivingdata comprising a securities order and conditions on said securitiesorder from a first securities market participant; (b) electronicallystoring said received data in a database; (c) electronically receivingand storing in said database data comprising contra securities ordersfrom other securities market participants; (d) searching with a firstprocessor in communication with said database for contra securitiesorders that satisfy said conditions on said securities order from saidfirst securities market participant; (e) ranking with a second processorcontra securities orders that satisfy said conditions according tocriteria comprising said conditions; and (f) routing with a thirdprocessor said securities order received from said first securitiesmarket participant or portions thereof to securities market participantsfrom which said ranked contra securities orders were received, accordingto ranking obtained in step (e), wherein said first, second, and thirdprocessors may the same processor, separate processors linked via acommunications link, or a combination thereof.
 2. A method according toclaim 1, wherein said conditions comprise having a designated portion ofsaid securities order sent out to third-party systems.
 3. A methodaccording to claim 2, wherein the aggregate size of portions of saidsecurities order that are routed to third-party systems does not exceedthe size of said securities order.
 4. A method according to claim 1,wherein a count is maintained of the residual size that has not beenrouted to likely contras, and said count is decremented when routed-tocontras decline to accept the securities order.
 5. A method according toclaim 4, wherein said residual size count is not permitted to becomenegative.
 6. A method according to claim 2, wherein said conditionscomprise a combination of possible third-party execution options.
 7. Amethod according to claim 1, wherein said first securities marketparticipant transmits said conditions by entering a script through agraphical user interface.
 8. A method according to claim 7, wherein saidscript specifies a sequence of operations to be executed in the processof working said securities order.
 9. A method according to claim 7,wherein said graphical user interface comprises a script-editing screendisplaying a blank horizontal field with a downward-pointing arrow. 10.A method according to claim 9, wherein upon clicking on thedownward-pointing arrow a drop list of securities order managementoptions appears for the user to choose from.
 11. A method according toclaim 7, wherein said graphical user interface displays a list ofsecurities order management options.
 12. A method according to claim 11,wherein said list of securities order management options includesoptions to route parts of the securities order to third party systems.13. A method according to claim 11, wherein said list of securitiesorder management options includes an option of sending targetednotifications of the residual part of the securities order that was notrouted to other parties in order to attract responsive securitiesorders.
 14. A method according to claim 11, wherein, upon selecting anoption from said list, a user enters a dialog to edit relevantdissemination parameters.
 15. A method according to claim 7, wherein auser specifies a time to be allotted for each step of said script.
 16. Asystem for managing orders in a financial securities market, comprising:(1) memory operable to store at least one program to and to store (a)data comprising a securities order and conditions on said securitiesorder, received from a first securities market participant; (b) datacomprising contra securities orders received from other securitiesmarket participants; (2) a first processor, in communication with saidmemory and executing at least part of said at least one program, thatsearches for contra securities orders that satisfy said conditions onsaid securities order from said first securities market participant; (e)a second processor, in communication with said memory and executing atleast part of said at least one program, that ranks contra securitiesorders that satisfy said conditions according to criteria comprisingsaid conditions; and (f) a third processor, in communication with saidmemory and executing at least part of said at least one program, thatroutes said securities order received from said first securities marketparticipant or portions thereof to securities market participants fromwhich said ranked contra securities orders were received, according tosaid ranking by said second processor, wherein said first, second, andthird processors may the same processor, separate processors linked viaa communications link, or a combination thereof.